Network Energy Saving Rel-19
Please refer to RP-234065 for detailed scope of
the WI.
[116-R19-NES] – Ajit (Ericsson)
Email discussion on Rel-19 NES enhancement
-
To be used for sharing updates on
online/offline schedule, details on what is to be discussed in online/offline
sessions, tdoc number of the moderator summary for online session, etc
R1-2401143 Workplan
for Rel-19 network energy savings WI Rapporteurs (Ericsson, Apple)
R1-2400119 On-demand SSB SCell operation for NES Huawei, HiSilicon
·
On-demand SSB triggering and its related
procedures should focus on the scenarios of SCell activation and measurements.
·
On-demand SSB based measurement should be
triggered by the gNB for at least SCell addition/modification.
o FFS: RAN4 RRM impacted requirements.
·
On-demand SSB on an SCell should be
triggered by gNB for the measurement and T/F synchronization in conjunction
with the activation command for SCell, simultaneously or separately.
·
Explicit on-demand SSB wake-up-signal for
uplink traffic could be considered by RAN1 if there is benefits.
·
RAN1 introduces DL on-demand SSB
activation/deactivation indication that can be used for at least SCell
addition/modification, SSB activation ahead of SCell activation command, and
the deactivation of SSB transmission on SCell. The timing of the DL on-demand
SSB activation/deactivation indication can be further discussed.
Decision:
The document is noted.
R1-2400492 Discussion on on-demand SSB for NES ZTE, Sanechips
·
On-demand SSB SCell for UEs in connected
mode should focus on the scenarios that SSB-less SCell are not supported.
·
An enhanced on-demand SSB transmission mode
should be considered after the on-demand SSB is triggered, i.e., SSB is
transmitted either in only several bursts or within a period after the
on-demand SSB is triggered.
·
There is no need to support on-demand SSB
before SCell activation command is received.
·
On-demand SSB can be supported during SCell
activation procedure.
·
On-demand SSB during SCell activation
procedure can be triggered by the SCell activation signaling.
·
On-demand SSB can be considered after SCell
activation, if needed
Decision:
The document is noted.
R1-2400062 Discussion on on-demand SSB SCell operation Spreadtrum
Communications
R1-2400097 Discussion of on-demand SSB Scell operation FUTUREWEI
R1-2400176 On-demand SSB SCell operation Ericsson
R1-2400180 On-demand SSB Scell Operation Nokia, Nokia Shanghai Bell
R1-2400208 Discussion on On-Demand SSB SCell operation Transsion
Holdings
R1-2400250 Discussions on on-demand SSB Scell operation vivo
R1-2400335 Discussion on on-demand SSB SCell operation CMCC
R1-2400369 Design of on-demand SSB SCell operation Intel Corporation
R1-2400399 On-demand SSB SCell Operation Google
R1-2400441 Discussion on on-demand SSB SCell operation CATT
R1-2400515 On-demand SSB delivery of NES cells Dell
Technologies
R1-2400525 Discussion on on-demand SSB SCell operation Honor
R1-2400566 Discussion on on-demand SSB SCell operation xiaomi
R1-2400599 Discussion on the enhancement to support on demand SSB
SCell operation OPPO
R1-2400667 Discussion on on-demand SSB operation for SCell China
Telecom
R1-2400740 On-demand SSB SCell operation Samsung
R1-2400806 Discussion on on-demand SSB for SCell operation NEC
R1-2400821 Discussion on On-demand SSB SCell operation InterDigital,
Inc.
R1-2400901 Discussion on on-demand SSB SCell operation Panasonic
R1-2400927 On-demand SSB SCell operation for NES Fraunhofer IIS,
Fraunhofer HHI
R1-2401020 On-demand SSB SCell operation Apple
R1-2401473 Discussion on on-demand SSB SCell operation NTPU (rev of R1-2401053)
R1-2401085 On-demand SSB SCell operation Lenovo
R1-2401123 Discussion on on-demand SSB SCell operation NTT
DOCOMO, INC.
R1-2401190 Discussion on On-demand SSB SCell operation ITRI
R1-2401196 On-demand SSB for SCell ASUSTeK
R1-2401206 Discussion on on-demand SSB SCell operation Fujitsu
R1-2401212 Discussion of on-demand SSB SCell operation CAICT
R1-2401232 Discussion on On-demand SSB SCell operation ETRI
R1-2401279 Discussion on on-demand SSB Scell operation CEWiT
R1-2401291 On-demand SSB SCell operation MediaTek Inc.
R1-2401332 On-demand SSB SCell operation LG Electronics
R1-2401449 On-demand SSB operation for Scell Qualcomm
Incorporated
R1-2401673 Summary #1 of on-demand SSB for NES Moderator (LG
Electronics)
From Wednesday session
Agreement
Regarding the UE
assumption on SSB transmission on a cell supporting on-demand SSB SCell
operation, the
following cases are identified for further study:
- Case #1: No
always-on SSB on the cell
- Case #2: Always-on
SSB is periodically transmitted on the cell
- FFS: Whether
always-on SSB and on-demand SSB are not cell-defining SSB if transmitted.
FFS: Which
scenario the above applies for
R1-2401674 Summary
#2 of on-demand SSB for NES Moderator (LG Electronics)
From Thursday session
Agreement
RAN1
to strive for a common design for on-demand SSB operation considering all
applicable CA configurations.
Agreement
- For
the following identified scenarios for on-demand SSB SCell operation,
focus future RAN1 discussion to down-select (both may be selected) between
the two scenarios.
- Scenario
#2: SCell is configured to a UE but before the UE receives SCell
activation command (e.g., as defined in TS 38.321)
- Scenario
#3: After UE receives SCell activation command (e.g., as defined in TS
38.321)
- This
does not preclude SCell for which activation is completed
- FFS:
The case where SCell activation is completed
FFS:
Application timing between NW triggering message and on demand SSB transmission
(Apple requested adding the above FFS)
R1-2401675 Summary
#3 of on-demand SSB for NES Moderator (LG Electronics)
From Friday session
Agreement
Support on-demand SSB SCell operation triggered by gNB.
·
FFS Details of associated
signaling/indication/configuration provided to UE
Agreement
- For
SSB burst(s) triggered by on-demand SSB SCell operation, study at least
the following options.
- Option
1: UE expects that on-demand
SSB
burst(s) is periodically transmitted from time instance A.
- Option
1A: UE expects that on-demand SSB burst(s) is periodically
transmitted from time instance A until gNB turns OFF the on demand SSB.
- Option
2: UE expects that on-demand
SSB
burst(s) is transmitted from time instance A to time instance B and not
transmitted after time instance B.
- Option
3: UE expects that on-demand
SSB
burst(s) is transmitted N times after time instance A and not transmitted
after N on-demand
SSB
bursts are transmitted.
- Option
4: UE expects that on-demand
SSB
burst(s) is transmitted with a periodicity from time instance A to time
instance B and with the other periodicity after time instance B.
- FFS:
The combination of above options.
- FFS:
How to define time instance A/B and the value of N per option.
- FFS:
Each option is applicable to which Cases or Scenarios (as per the
previous agreement).
Final
summary in R1-2401840.
R1-2400442 Discussion on on-demand SIB1 CATT
·
If on-demand SIB1 is
considered for heterogeneous network deployment, specification impact and
implementation complexity need further study.
·
If on-demand SIB1 is
supported, preamble can be considered as UL WUS transmitted by idle/inactive
mode UE for triggering on-demand SIB1.
·
If on-demand SIB1 is
supported, at least UL WUS configuration provided by non-NES cell should be
supported.
·
If on-demand SIB1 is
supported, the triggering condition for UL WUS transmission should be further
studied.
·
If on-demand SIB1 is
supported and the UL WUS configuration is provided by a non-NES cell, the
following two options for UL WUS transmission may be considered:
o
Option 1: Rel-19
idle/inactive mode UE transmits UL WUS to the non-NES cell where UL WUS
configuration is received.
o
Option 2: Rel-19
idle/inactive mode UE transmits UL WUS to the NES cell without SIB1
transmission directly.
·
If on-demand SIB1 is
supported, the confirmation of reception of UL WUS transmission should be
supported to guarantee the understanding of SIB1 transmission decision between
NES mode cell and UE is aligned.
Decision:
The document is noted.
R1-2401144 Study of on-demand SIB1 for UEs in idle/inactive mode for
NES Ericsson
·
In the study of on-demand
SIB1, given the limited network energy saving gains expected, complex solutions
should be avoided.
·
A cell with on-demand SIB1
transmission must transmit SSB, listen in case of a WUS transmission from a
SIB1 requesting UE and offer paging occasions, so that it can support
idle/inactive UEs.
·
Regardless of deployment
scenario, transmission of SIB1 on-demand is only supported if coverage holes
can be avoided for legacy UEs.
·
WUS configuration
provisioning by an anchor cell and WUS reception on non-anchor/NES cell along
with transmission of SIB1 by the non-anchor/NES cell should be included in the
study.
·
For the study of procedures
and signaling for operation of a cell with on-demand SIB1 (or NES cell), study
the following options:
o
Option 1 (single cell case:
NES cell)
§
UE obtains a WUS
configuration from NES cell
§
UE transmits WUS requesting
SIB1 to NES cell
§
NES cell transmits SIB1
o
Option 2 (two cell case:
anchor cell and NES cell)
§
UE obtains a WUS
configuration for NES cell via signalling from an anchor cell
§
UE transmits WUS requesting
SIB1 to NES cell
§
NES cell transmits SIB1
·
For the study of procedures
and signaling for operation of a cell with on-demand SIB1 (or NES cell), the
assumption on the transmission/reception of the following channels/signals on
the NES cell should be clarified.
o
SSB transmission
o
WUS configuration
transmission (for requesting SIB1)
o
WUS reception
o
SIB1 transmission
o
Initial access/RACH
procedure (including RACH periodicity)
o
Paging transmission
o
OSI transmission
·
In the study of procedures
and signaling for on-demand SIB1, the uplink wake-up-signal transmitted by the
UE is based on PRACH.
Decision:
The document is noted.
R1-2400063 Discussion on on-demand SIB1 for idle/inactive mode UEs Spreadtrum
Communications
R1-2400098 Discussion of on-demand SIB1 for idle/inactive mode UEs FUTUREWEI
R1-2400120 Discussion on on-demand SIB1 for NES Huawei,
HiSilicon
R1-2400181 On-demand SIB1 for Idle/Inactive mode UEs Nokia,
Nokia Shanghai Bell
R1-2400209 Discussion on on-demand SIB1 transmission Transsion
Holdings
R1-2401565 Discussions on on-demand SIB1 for idle/inactive mode UEs vivo (rev
of R1-2401536; rev of R1-2400251)
R1-2400336 Discussion on-demand SIB1 for UEs in idle/inactive mode CMCC
R1-2400370 Study of on-demand SIB1 for idle/inactive mode UEs Intel
Corporation
R1-2400400 On-demand SIB1 for Idle/Inactive Mode UE Google
R1-2400493 Discussion on on-demand SIB1 for UEs in idle or inactive
mode ZTE, Sanechips
R1-2400567 Discussion on on-demand SIB1 for idle/inactive mode UEs xiaomi
R1-2400600 Discussion on the enhancement to support on demand SIB1 for
idle/inactive mode UE OPPO
R1-2400668 Discussion on on-demand SIB1 for idle/inactive mode UEs China
Telecom
R1-2400741 On-demand SIB1 for idle/inactive mode UEs Samsung
R1-2400807 Discussion on on-demand SIB1 for UEs in idle/inactive mode NEC
R1-2400822 Discussion on On-demand SIB1 for idle/inactive mode UEs InterDigital,
Inc.
R1-2400861 Considerations on on-demand SIB1 for idle/inactive mode UEs Sony
R1-2400902 Discussion on on-demand SIB1 for idle/inactive mode UEs Panasonic
R1-2400928 On-demand SIB1 for NES Fraunhofer IIS, Fraunhofer HHI
R1-2401021 On On-demand SIB1 for IDLE/INACTIVE mode UEs Apple
R1-2401474 Scope of on-demand SIB study NTPU (rev of R1-2401054)
R1-2401086 On-demand SIB1 for idle/inactive mode UEs Lenovo
R1-2401124 Discussion on on-demand SIB1 for idle/inactive mode UEs NTT
DOCOMO, INC.
R1-2401176 Discussion on on-demand SIB1 transmission for idle UEs Sharp
R1-2401197 Triggering of on-demand SIB1 ASUSTeK
R1-2401204 Discussion on on-demand SIB1 transmission for network
energy savings Fujitsu
R1-2401233 Discussion on on-demand SIB1 for idle/inactive mode UEs ETRI
R1-2401253 Views on On-demand SIB1 operation for idle/inactive UEs Vodafone
R1-2401280 Discussion on on-demand SIB1 CEWiT
R1-2401292 On-demand SIB1 for idle or inactive mode UEs MediaTek
Inc.
R1-2401333 On-demand SIB1 for idle/inactive mode UEs LG
Electronics
R1-2401450 On-demand SIB1 procedure Qualcomm Incorporated
R1-2401661 FL summary 1 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From
Wednesday session
Agreement
For
discussion purpose, the following assumption will be used in RAN1
- Cell A:
A cell that is periodically transmitting at least its own SIB1
- NES
Cell: A cell that may transmit SIB1 transmission in response to UL WUS
from a UE
For the
further study of on-demand SIB1 for idle/inactive mode UE, RAN1 studies the
following options.
On target
cell of UL WUS transmission:
- Option
1: UE transmits UL WUS to NES Cell
- Option
2: UE transmits UL WUS to Cell A
On
configuration provision for UL WUS transmission
- Option
A: UE obtains the UL WUS configuration from NES Cell
- Option
B: UE obtains the UL WUS configuration from Cell A
Other
options are not precluded
R1-2401662 FL summary 2 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Thursday session
Agreement
For
further study of achievable NES gain with on-demand SIB1 for idle/inactive mode
UE,
Note: Other
SSB/SIB1 periodicity assumptions are not precluded (up to companies to report)
- 4
or 8 SSBs in a SSB burst with SSB pattern case C
- 20ms
or 160ms PRACH monitoring period
- Assume
the following for network energy evaluation of NES cell in FR1:
- Empty/low/medium
cell load as defined in 38.864
- Cat
1/Cat 2 BS as defined in 38.864
- 30kHz
SCS, DDDSU TDD pattern
- Case
1: 20ms SSB period with no SIB1 transmitted;
Note: Other SSB/SIB1 assumptions are
not precluded (up to companies to report)
- 4
or 8 SSBs in a SSB burst with SSB pattern case C
- 20ms/160ms
UL WUS monitoring period
- Note:
SSB/CORESET0 multiplexing pattern 1 is used
Agreement
- For
study of UL WUS design,
consider at least PRACH as a starting point
- FFS:
Whether there is dedicated PRACH resource for SIB1 request
- Other
option(s) not precluded
Agreement
For
the further study of on-demand SIB1 for idle/inactive mode UE, RAN1 to discuss
triggering conditions for sending UL-WUS.
Agreement
For
the study of on-demand SIB1 for
idle/inactive mode UE, RAN1 to further study whether feedback from gNB in response to
the SIB1 request is supported including associated details.
R1-2401663 FL summary 3 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Friday session
Agreement
For the further study on UL WUS configuration among the following options:
·
Option 1: Pre-defined UL
WUS configuration.
·
Option 2: UL WUS
configuration that applies to multiple NES cell.
·
Option 3: UL WUS
configuration that applies to a single NES cell.
R1-2400371 Adaptation of common signal/channel transmissions for
Network Energy Saving Intel Corporation
·
RAN1 to discuss the
following potential approaches for SSB transmission periodicity adaptation:
o
Option 1) Introduction of
new SSB periodicities
§
FFS: periodicity values
o
Option 2) Introduction of
new SSB transmission pattern, including clustering of SSB transmissions:
§
FFS: SSB pattern, slot
configuration
o
For both options further
study on impact on legacy UEs is needed.
·
RAN1 to investigate
introduction of the time domain clustering of PRACH resources
o
FFS: supported PRACH
resource pattern and resource configuration
o
FFS: impact on legacy UEs
and how to multiplex legacy PRACH resources with newly introduced clustered
PRACH resources
·
RAN1 to study non-uniform
resources assignment of PRACH occasions for different SSB beams, including
evaluation of potential energy saving benefits
o
FFS: details of non-uniform
resource allocation for PRACH for each SSB beam
·
RAN1 should investigate
further into techniques that allow compacting paging resources into consecutive
slots/frames.
Decision:
The document is noted.
R1-2400064 Discussion on adaptation of common signal/channel
transmissions Spreadtrum Communications
R1-2400099 Discussion of the adaptation of common signal/channel
transmissions FUTUREWEI
R1-2400121 Adaptation of common signal/channel transmissions Huawei,
HiSilicon
R1-2400182 Adaptation of common signal/channel transmissions Nokia,
Nokia Shanghai Bell
R1-2400210 Discussion on adaptive transmission of common signal or
common channel Transsion Holdings
R1-2400252 Discussions on adaptation of common signal/channel
transmissions vivo
R1-2400337 Discussion on adaptation of common signal/channel
transmissions CMCC
R1-2400401 Adaptation of Common Signals Google
R1-2400443 Discussion on adaptation of common signal/channel
transmissions CATT
R1-2400494 Discussion on common signal_channel for NES ZTE,
Sanechips
R1-2400526 Discussion on adaptation of common signal channel
transmissions Honor
R1-2400568 Discussion on adaptation of common signal and channel
transmissions xiaomi
R1-2400601 Discussion on adaptation of common signal/channel
transmission OPPO
R1-2400669 Discussion on common signal/channel adaptation China
Telecom
R1-2400742 Adaptation of common signal/channel transmissions Samsung
R1-2400808 Discussion on adaptation of common signal/channel
transmissions for Cell DTX/DRX NEC
R1-2400823 Discussion on adaptation of common signal/channel
transmissions InterDigital, Inc.
R1-2400862 Considerations on adaptation of SSB in time domain Sony
R1-2400903 Discussion on adaptation of common signal/channel
transmission Panasonic
R1-2400929 Adaptation of Common Signals and Channels for NES Fraunhofer
IIS, Fraunhofer HHI
R1-2400979 Adaptation of common signals and channels Lenovo
R1-2401022 On adaptation of common signal/channel for NES enhancements Apple
R1-2401125 Discussion on adaptation of common signal/channel
transmissions NTT DOCOMO, INC.
R1-2401145 Adaptation of common signal/channel transmissions for NES Ericsson
R1-2401149 Views on adaptation of SS/PBCH blocks KT Corp.
R1-2401177 Discussion on adaptation of common signal/channel
transmissions Sharp
R1-2401205 Discussion on adaptation of common signal / channel
transmissions Fujitsu
R1-2401234 Adaptation of common signal/channel transmissions ETRI
R1-2401281 Discussion on adaptation of common signal and channel
transmissions CEWiT
R1-2401293 Adaptation of common signal/channel transmissions MediaTek
Inc.
R1-2401334 Adaptation of common signal/channel transmissions LG
Electronics
R1-2401451 Adaptation of common channel transmissions Qualcomm
Incorporated
R1-2401728 Summary#1 of AI
9.5.3 for R19 NES Moderator (Ericsson)
From
Wednesday session
Agreement
For
adaptation of SSB in time-domain, consider the following adaptation mechanisms
for further study
- Adaptation of SSB burst periodicity
- Adaptation based on two SSB configurations where
up to two configurations can be active
- Adaptation
based on skipping/transmitting some SSB bursts non-uniformly with single
SSB configuration
- Adapting
the transmitted number of SSBs within a SSB burst
- Cell DTX for SSB adaptation
- Whether to support new SSB burst periodicity
value(s)
- Whether to support new SSB burst(s) (i.e. how SSB
transmission is made within a burst)
- New compact SSB burst(s)
- Adapting the position of SSBs within a SSB burst
- Other mechanisms/combinations are not precluded
R1-2401821 Summary#2 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From
Thursday session
Agreement
For adaptation of PRACH
in time-domain, consider the following adaptation mechanisms for further study
- Adaptation
based on configuration of additional[/different] PRACH resources for
NES-capable UEs in addition to PRACH resources for legacy UEs (if any)
- Note:
NES-capable UEs can use both additional PRACH resources and PRACH
resources for legacy UEs
- For
the additional PRACH resources,
- Adaptation
of PRACH resource periodicity/PRACH occasion
- Adaptation
at PRACH configuration/association period/association pattern period
level and SSB to RO mapping cycle
- Adaptation
based on extending cell DRX operation for PRACH
- Concentrating
ROs in time domain
- Other
options are not precluded
Agreement
For adaptation of
paging,
- Study
further from RAN1 perspective, techniques for adaptation of paging
occasions in time-domain and achievable network energy savings
- Note:
Specification details for PO/PF determination and paging-related
configuration/procedures to be handled by RAN2
Agreement
For the adaptation
mechanisms of SSB in time-domain, study further applicable scenarios and
associated legacy UE impact/handling (if any) based on the following:
- Applicability
to UE in idle/inactive and/or connected mode
- Applicability
to PCell and/or SCell(s)
Agreement
For the adaptation
mechanisms of SSB in time-domain, study further following mechanisms:
- Adaptation
mechanism indicated or configured by gNB without UE trigger
- Adaptation
triggered by UE (if any)
FFS:
Details of associated signaling/indication/configuration.
R1-2401856 Summary#3 of AI
9.5.3 for R19 NES Moderator (Ericsson)
From
Friday session
Agreement
For the adaptation
mechanisms of PRACH in time-domain
·
Support at least PRACH
adaptation provided by gNB without UE trigger
o
FFS: PRACH adaptation with
UE trigger
o
Note: UE trigger means UE
requests adaptation of PRACH
·
Study at least the
following,
o
Dynamic signaling and/or
semi-static signaling of PRACH adaptation
o
Adaptation of PRACH
transmission according to certain condition
o
Applicability to
idle/inactive and/or connected mode UEs
o
Which scenarios the
adaptation mechanism is applicable to (e.g. cell with both legacy and Rel-19
UE, cell with only Rel-19 UEs)
Final
summary in R1-2401870.
Please refer to RP-240170 for detailed scope of
the WI.
[116bis-R19-NES] – Ajit (Ericsson)
Email discussion on Rel-19 NES enhancement
-
To be used for sharing updates on
online/offline schedule, details on what is to be discussed in online/offline
sessions, tdoc number of the moderator summary for online session, etc
R1-2403272 Updated workplan for Rel-19 network energy savings WI Rapporteurs
(Ericsson, Apple)
R1-2401985 On-demand SSB SCell Operation Nokia, Nokia Shanghai Bell
R1-2402029 Discussion on on-demand SSB SCell operation for NES Huawei,
HiSilicon
R1-2402048 Discussion of on-demand SSB Scell operation FUTUREWEI
R1-2402111 Discussion on on-demand SSB SCell operation Spreadtrum
Communications
R1-2402149 Design of on-demand SSB SCell operation Intel Corporation
R1-2402190 Discussion on on-demand SSB for NES ZTE, Sanechips
R1-2402248 Discussions on on-demand SSB Scell operation vivo
R1-2402283 On-demand SSB SCell Operation Google
R1-2402334 Discussion on the enhancement to support on demand SSB
SCell operation OPPO
R1-2402389 Discussion on on-demand SSB SCell operation CATT
R1-2402472 On-demand SSB SCell operation Samsung
R1-2402516 Discussion on on-demand SSB operation for SCell China
Telecom
R1-2402536 Discussion on On-demand SSB SCell operation Mavenir
R1-2402541 Discussion on on-demand SSB SCell operation Panasonic
R1-2402571 Discussion on on-demand SSB SCell operation CMCC
R1-2402637 Discussion on on-demand SSB SCell operation InterDigital,
Inc.
R1-2402672 Discussion on on-demand SSB SCell operation Xiaomi
R1-2402690 Discussion on On-Demand SSB SCell operation Transsion
Holdings
R1-2402726 Discussion on on-demand SSB SCell operation Honor
R1-2402809 Discussion on On-demand SSB SCell operation ITRI
R1-2402819 On-demand SSB for SCell ASUSTeK
R1-2402828 Discussion on on-demand SSB for SCell operation NEC
R1-2402832 Discussion on on-demand SSB SCell operation Fujitsu
R1-2402887 On-demand SSB SCell Operation Apple
R1-2402930 On-demand SSB SCell operation Lenovo
R1-2402942 On-demand SSB SCell operation MediaTek
R1-2402973 On-demand SSB SCell operation Sony
R1-2403024 Discussion on On-demand SSB SCell operation ETRI
R1-2403063 Discussion on on-demand SSB Scell operation CEWiT
R1-2403123 On-demand SSB SCell operation LG Electronics
R1-2403134 On demand SSB Scell operation for NES KDDI Corporation
R1-2403200 On-demand SSB operation for Scell Qualcomm
Incorporated
R1-2403250 Discussion on on-demand SSB SCell operation NTT
DOCOMO, INC.
R1-2403273 On-demand SSB SCell operation Ericsson
R1-2403301 Discussion on on-demand SSB SCell operation Sharp
R1-2403304 On-demand SSB SCell operation for NES Fraunhofer IIS,
Fraunhofer HHI
R1-2403308 Discussion of on-demand SSB SCell operation CAICT
R1-2403506 Summary #1 of on-demand SSB for NES Moderator (LG
Electronics)
Presented in Tuesday session
R1-2403507 Summary #2 of on-demand SSB for NES Moderator (LG
Electronics)
Presented in Wednesday session
R1-2403508 Summary #3 of on-demand SSB for NES Moderator (LG
Electronics)
From Thursday session
Agreement
For the identified
scenarios
and cases (as per RAN1#116 agreement),
on-demand SSB can be triggered by gNB at least for the following
scenarios/cases:
- Scenario #2 and Case #1
- Scenario #2 and
Case #2
- Scenario #2A and Case #1
- Scenario #2A and
Case #2
- FFS: Scenario #3A and
Case #1
- FFS: Scenario #3A and Case #2
- FFS: Scenario #3B
and Case #1
- FFS: Scenario #3B
and Case #2
- For Case #1, once
on-demand SSB is triggered, its transmission is in a periodic manner.
- Note: This does
not imply periodic on-demand SSB is transmitted indefinitely after
triggered.
- Notes:
- Scenario #2A
refers to
- “When UE receives SCell
activation command (e.g., as defined in TS 38.321)”
- Scenario #3A
refers to
- “After UE receives
SCell activation command (e.g., as defined in TS 38.321) until SCell
activation is completed”
- Scenario #3B
refers to
- “When SCell
activation is completed and SCell is activated” or
- “After SCell
activation is completed and SCell is activated”
- For discussion
purpose
under AI 9.5.1,
always-on SSB is SSB
supported in Rel-18 specifications.
- Timing for
on-demand SSB transmission (e.g. when the triggered SSB starts and ends)
will be separately discussed.
Agreement
For a cell
supporting on-demand SSB SCell operation,
- Note: It is up to gNB
implementation whether always-on SSB (if transmitted) on the cell is
cell-defining SSB or not.
- For on-demand SSB on the cell,
downselect between the following alternatives
- Alt-1: It is up to gNB
implementation whether on-demand SSB is cell-defining SSB or not.
- Alt-2: On-demand SSB is
limited to non-cell-defining SSB.
- FFS: Further limitations to
on-demand SSB
Agreement
For a cell
supporting on-demand SSB SCell operation,
- L1
and/or L3 measurement based on on-demand SSB is supported for the cell.
- FFS
further details on L1 and/or L3 measurement
R1-2403509 Summary #4 of on-demand SSB for NES Moderator (LG
Electronics)
From Friday session
Agreement
The
following agreement from RAN1#116 is modified (in red)
- For
SSB burst(s)
triggeredindicated by on-demand SSB SCell operation, study
at least the following options.
- Option
1: UE expects that on-demand
SSB
burst(s) is periodically transmitted from time instance A.
- Option
1A: UE expects that on-demand SSB burst(s) is periodically
transmitted from time instance A until gNB turns OFF the on demand SSB
- Option
2: UE expects that on-demand
SSB
burst(s) is transmitted from time instance A to time instance B and not
transmitted after time instance B.
- Option
3: UE expects that on-demand
SSB
burst(s) is transmitted N times after time instance A and not transmitted
after N on-demand
SSB
bursts are transmitted.
- Option
4: UE expects that on-demand
SSB
burst(s) is transmitted with a periodicity from time instance A to time
instance B and with the other periodicity after time instance B.
- FFS:
The combination of above options
- FFS:
How to define time instance A/B and the value of N per option
- FFS:
Each option is applicable to which Cases or Scenarios (as per the
previous agreement)
Agreement
For a cell supporting
on-demand SSB SCell operation,
further study the
following options.
- Option 1: Separate signaling
between legacy/existing signaling (e.g., RRC, MAC CE) providing SCell
activation/deactivation and signaling providing On-demand SSB transmission
indication.
- Option 2: A single signaling
in which both SCell activation/deactivation and On-demand SSB transmission
indication are provided.
- FFS: Details of the signaling
- Other options are not
precluded.
- FFS: Details on On-demand SSB transmission
indication
Final summary in R1-2403765.
R1-2401986 On-demand SIB1 for Idle/Inactive mode UEs Nokia,
Nokia Shanghai Bell
R1-2402030 Discussion on on-demand SIB1 for NES Huawei,
HiSilicon
R1-2402049 Discussion of on-demand SIB1 for idle/inactive mode UEs FUTUREWEI
R1-2402112 Discussion on on-demand SIB1 for idle/inactive mode UEs Spreadtrum
Communications
R1-2402191 Discussion on on-demand SIB1 for UEs in idle or inactive
mode ZTE, Sanechips
R1-2402249 Discussions on on-demand SIB1 for idle/inactive mode UEs vivo
R1-2402284 On-demand SIB1 for Idle/Inactive Mode UE Google
R1-2402335 Discussion on the enhancement to support on demand SIB1 for
idle/inactive mode UE OPPO
R1-2402390 Discussion on on-demand SIB1 CATT
R1-2402473 On-demand SIB1 for idle/inactive mode UEs Samsung
R1-2402517 Discussion on on-demand SIB1 for idle/inactive mode UEs China
Telecom
R1-2402542 Discussion on on-demand SIB1 for idle/inactive mode UEs Panasonic
R1-2402572 Discussion on-demand SIB1 for UEs in idle/inactive mode CMCC
R1-2402673 Discussion on on-demand SIB1 for idle/inactive mode UEs Xiaomi
R1-2402683 Discussion on on-demand SIB1 for idle/inactive mode UEs InterDigital,
Inc.
R1-2402691 Discussion on on-demand SIB1 transmission for idle/inactive
mode UEs Transsion Holdings
R1-2402820 Triggering of on-demand SIB1 ASUSTeK
R1-2402823 On-demand SIB1 for Idle/Inactive mode UEs III
R1-2402829 Discussion on on-demand SIB1 for UEs in idle/inactive mode NEC
R1-2402833 Discussion on on-demand SIB1 transmission for network
energy savings Fujitsu
R1-2402888 On on-demand SIB1 for IDLE/INACTIVE mode UE Apple
R1-2402931 On-demand SIB1 for idle/inactive mode UEs Lenovo
R1-2402943 On-demand SIB1 for idle or inactive mode UEs MediaTek
R1-2402974 Considerations on on-demand SIB1 for idle/inactive mode UEs Sony
R1-2403003 Views on On-demand SIB1 operation for idle/inactive UEs Vodafone
R1-2403025 On-demand SIB1 for idle/inactive mode UEs for NES ETRI
R1-2403064 Discussion on on-demand SIB1 CEWiT
R1-2403124 On-demand SIB1 for idle/inactive mode UEs LG
Electronics
R1-2403201 On-demand SIB1 procedure Qualcomm Incorporated
R1-2403251 Discussion on on-demand SIB1 for idle/inactive mode UEs NTT
DOCOMO, INC.
R1-2403274 Study of on-demand SIB1 for UEs in idle/inactive mode for
NES Ericsson
R1-2403302 Discussion on on-demand SIB1 transmission for idle UEs Sharp
R1-2403305 On-demand SIB1 for NES Fraunhofer IIS, Fraunhofer HHI
R1-2403390 Discussion on On-demand SIB1 for idle/inactive mode UEs DENSO
CORPORATION
R1-2403527 FL summary 1 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Tuesday session
Agreement
For the
further study of on-demand SIB1 for idle/inactive mode UE, RAN1 focuses its
studies on the following cases:
- Case 1: Option 1+A+X
- Case 2: Option 1+B+X
- Case 3: Option 2+B+Y
Where the
options 1/2/A/B/X/Y are defined below:
·
On target cell of UL WUS transmission:
o Option
1: UE transmits UL WUS to NES Cell
o
Option 2: UE transmits UL WUS to Cell A
·
On configuration provision for UL WUS
transmission
o Option
A: UE obtains the UL WUS configuration from NES Cell
o
Option B: UE obtains
the UL WUS configuration from Cell A
·
On receiving of SIB1
o
Option X: UE receives on-demand SIB1 from
NES Cell
o
Option Y: UE receives on-demand SIB1 from
Cell A
Agreement
RAN1
to further study the
following UE operation scenarios in the UL WUS design:
·
Scenario 1: UE requests SIB1 to camp on NES
cell
·
Scenario 2: UE request SIB1 to perform
random access procedure to make RRC connection to NES cell
R1-2403528 FL summary 2 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Wednesday session
Agreement
RAN1 to further study UE identification of NES cell with
on-demand SIB1 based on one, both, or combination of the following options:
·
Option 1: By WUS configuration
·
Option 2: By PBCH payload of NES cell
R1-2403529 FL summary 3 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Thursday session
Agreement
Companies to report at least the following key settings used in the evaluation/simulation of achievable NES gain with on-demand
SIB1 in idle/inactive mode
·
Setting A: SIB1 period
(20ms/40ms/160ms)
·
Setting B1: Cell load
(Empty/low/medium)
·
Setting B2: Traffic model
·
Setting C: SIB1 PDSCH time
domain resource index in 38.214 Table 5.1.2.1.1-2
·
Setting D: CORESET0/SSB
multiplexing pattern including controlResourceSetZero (index) in 38.213
Table 13-6, and searchSpaceZero (index) in 38.213 Table 13-11
·
Setting E: PRACH
configurations (including PRACH configuration index in 38.211 Table 6.3.3.2-3)
for WUS and initial/random access
·
Setting F: Cat1/Cat2 BS
·
Setting G: Number of SSB
beams
·
Setting H: NES gain/loss on
Cell A
o
Further discuss in
RAN1#116bis on the evaluation assumptions for Cell A
·
Setting I: On-demand SIB1
transmission rate (how often UE requests on-demand SIB1)
R1-2403530 FL summary 4 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Friday session
Agreement
For
further study of the NES gain/loss evaluation assumption on Cell A with
on-demand SIB1 on NES cell for idle/inactive mode UE,
- Assume
the following for network energy evaluation of Cell A in FR1:
- Company
to report among empty/low/medium cell load as defined in 38.864
- Same
Cat BS as the Non-NES cell
- 30kHz
SCS, DDDSU TDD pattern
- Same
SSB period as the Non-NES cell and company to report SIB1 period
- Same
number of SSBs in a SSB burst as the Non-NES cell with SSB pattern case C
- 20ms
PRACH configuration periodicity for WUS and/or initial access RACH and
company to report RACH configuration index in 38.211 Table 6.3.3.2-3
- Same
SSB/CORESET0 multiplexing pattern and same SIB1 PDSCH time domain
resource allocation as the Non-NES cell
- Same
traffic model as the Non-NES cell
- Companies
to report the assumption of WUS configuration provision or UL WUS
monitoring or on-demand SIB1 transmission on Cell A if Case 2 (Option
1+B+X) or Case 3 (Option 2+B+Y) is considered
Agreement
For UL WUS design for SIB1
request, at least dedicated
PRACH
resource is the assumption for further study in RAN1
·
FFS: Details on time,
frequency, and/or PRACH preamble resources for UL WUS
·
FFS: whether RACH resource for SIB1 request
could be used for an initial access procedure and/or an on-demand SI procedure
Companies
to consider the following for future meetings
·
Option 1: SIB1 monitoring occasions within a
time window
o
FFS: The starting time and duration of the
time window
o
FFS: Interval between two SIB1 monitoring
occasions in the time window
o
FFS: How gNB informs UE the details related
to the time window
·
Option 2: Periodic SIB1 monitoring occasions
until gNB turns off the SIB1 transmission
o
FFS: The staring time of the SIB1 monitoring
occasions
o
FFS: How gNB informs UE the SIB1
transmission is turned off
o
FFS: How gNB informs the UE the details
related to periodicity
·
Other options are not precluded
·
FFS: Further details on SIB1 monitoring
occasions
Agreement
Conditions
for triggering UL WUS transmission is up to RAN2. Any related work in RAN1 to
be triggered by RAN2 LS. Send an LS to RAN2.
R1-2403778 Draft LS on the conditions for triggering UL WUS
transmission to request on-demand SIB1 MediaTek Inc.
Friday decision: The draft LS is endorsed assuming "kindly" to be replaced
by "respectfully". Final LS is approved
in R1-2403779.
Final summary in R1-2403729.
R1-2401987 Adaptation of common signal/channel transmissions Nokia,
Nokia Shanghai Bell
R1-2402031 Adaptation of common signal/channel transmissions Huawei,
HiSilicon
R1-2402050 Discussion of the adaptation of common signal/channel
transmissions FUTUREWEI
R1-2402113 Discussion on adaptation of common signal/channel
transmissions Spreadtrum Communications
R1-2402151 Adaptation of common signal/channel transmissions for
Network Energy Saving Intel Corporation
R1-2402192 Discussion on common signal_channel for NES ZTE,
Sanechips
R1-2402250 Discussions on adaptation of common signal/channel
transmissions vivo
R1-2402285 Adaptation of Common Signals Google
R1-2402336 Discussion on adaptation of common signal/channel
transmission OPPO
R1-2402391 Discussion on adaptation of common signal/channel
transmissions CATT
R1-2402405 Adaptation of common signal/channel transmissions for
network energy saving Tejas Network Limited
R1-2402474 Adaptation of common signal/channel transmissions Samsung
R1-2402518 Discussion on common signal/channel adaptation China
Telecom
R1-2402543 Discussion on adaptation of common signal/channel
transmission Panasonic
R1-2402573 Discussion on adaptation of common signal/channel
transmissions CMCC
R1-2402674 Discussion on adaptation of common signal and channel
transmissions Xiaomi
R1-2402692 Discussion on adaptive transmission of common signal or
common channel Transsion Holdings
R1-2402693 Discussion on adaptation of common signal/channel
transmissions InterDigital, Inc.
R1-2402727 Discussion on adaptation of common signal channel
transmissions Honor
R1-2402798 Discussion on adaptation of common signal/channel
transmissions Fujitsu
R1-2402830 Discussion on adaptation of common signal/channel
transmissions for Cell DTX/DRX NEC
R1-2402889 On adaptation of common signal/channel for NES enhancements Apple
R1-2402944 Adaptation of common signal/channel transmissions MediaTek
R1-2402975 Considerations on adaptation of common signal/channel
transmissions Sony
R1-2403026 Adaptation of common signal/channel transmissions for NES ETRI
R1-2403047 Adaptation of common signals and channels Lenovo
R1-2403065 Discussion on adaptation of common signal and channel
transmissions CEWiT
R1-2403125 Adaptation of common signal/channel transmissions LG
Electronics
R1-2403136 Adaptation of common signal/channel transmissions KDDI
Corporation
R1-2403137 Views on adaptation of common signal/channel transmissions KT
Corp.
R1-2403202 Adaptation of common channel transmissions Qualcomm
Incorporated
R1-2403252 Discussion on adaptation of common signal/channel
transmissions NTT DOCOMO, INC.
R1-2403275 Adaptation of common signal/channel transmissions for NES Ericsson
R1-2403303 Discussion on adaptation of common signal/channel
transmissions Sharp
R1-2403306 Adaptation of Common Signals and Channels for NES Fraunhofer
IIS, Fraunhofer HHI
R1-2403391 Discussion on Adaptation of common signal/channel
transmissions DENSO CORPORATION
R1-2403531 Summary#1 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Tuesday session
Agreement
For indication of adaptation of SSB in
time-domain,
·
Support at least SSB
adaptation provided by gNB without UE trigger
R1-2403532 Summary#2 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Wednesday session
Agreement
For
adaptation of PRACH in time-domain, support at least the following:
- Adaptation
based on additional PRACH resources for NES-capable UEs in addition to
PRACH resources for legacy UEs (if any)
- Note:
NES-capable UEs can use both additional PRACH resources and PRACH
resources for legacy UEs
- Configuration
of additional PRACH resources is provided by semi-static signalling
- FFS:
details including whether there is overlap of additional PRACH resources
and PRACH resources for legacy UEs
- FFS:
adaptation mechanism for additional PRACH resources
- Note:
No change to the existing PRACH configuration tables in 38.211
Agreement
For
adaptation of PRACH in time-domain, support the following:
- SSB-RO
mapping for the additional PRACH resources is separate from the SSB-RO
mapping of the PRACH resources for legacy UEs (if any)
- FFS:
whether/how to handle SSB-RO mapping if the additional PRACH resources
overlap in both time and frequency with the PRACH resources for legacy
UEs
- Note:
SSB-RO mapping of the PRACH resources for legacy UEs is not impacted if
Rel-19 UE uses these PRACH resources
- FFS:
SSB-RO mapping for the additional PRACH resources
Agreement
Support adaptation
mechanisms of PRACH in time-domain for following:
·
UE in idle/inactive mode
·
UE in connected mode
R1-2403691 Summary#3 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Thursday session
Agreement
Adaptation mechanism(s) of SSB in
time-domain is supported at least for one of the following scenario(s):
- For
cell with both legacy UEs and Rel-19 NES-capable UEs
- Rel-19
NES-capable UE’s PCell (Connected mode)
- Study
from the following options:
- Rel-19
NES-capable UE’s SCell
- Study
from the following options:
- Option
B1: adaptation for CD-SSB
- Option
B2: adaptation for SSB that is not CD-SSB
- Option
B3: adaptation for SSB not on sync raster
- FFS:
Rel-19 NES-capable UE in idle/inactive mode
- Note:
Impact to idle/inactive UEs shall be minimized
R1-2403692 Summary#4 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Friday session
Agreement
For
adaptation of PRACH in spatial domain,
·
Study possibility of
scenarios with non-uniform distribution of UEs in different beams
o
Note 6: Companies are
encouraged to provide details on how they map UEs to different beams
·
Study network energy
savings gain achieved by non-uniform PRACH resource
allocation across SSBs for scenarios with non-uniform
distribution of UEs in different beams (if any),
o
Assume the following
framework for network energy evaluation in FR1 and companies to report at least
the below settings used in the evaluation/simulation
§
20ms SSB period
§
30kHz SCS, DDDSU TDD
pattern
§
Setting A: SIB1 period
(20ms/40ms/160ms)
§
Setting B1: Cell load
(Empty/low/medium)
§
Setting B2: Traffic model
§
Setting C: SIB1 PDSCH time
domain resource index in 38.214 Table 5.1.2.1.1-2
§
Setting D: CORESET0/SSB
multiplexing pattern including controlResourceSetZero (index) in 38.213 Table
13-6, and searchSpaceZero (index) in 38.213 Table 13-11
§
Setting E1: PRACH
configurations
·
(legacy) PRACH resources according
to the following PRACH configuration for all transmitted SSBs
o
Case A1-1: PRACH
configuration #5 (20ms)
o
Case A1-2: PRACH
configuration #17 (10ms)
o
Case A2-1: PRACH
configuration #0 (160ms)
·
(time-domain PRACH
adaptation) Additional and legacy PRACH resources yielding total PRACH
resources that are according to one of the following PRACH configuration for
all transmitted SSBs
o
Case B1: PRACH
configuration #17 (10ms)
o
Case B2: PRACH
configuration #0 (160ms)
o
Companies to report details
of assumed time domain adaptation mechanism
·
(spatial-domain PRACH
adaptation) Additional and legacy PRACH resources yielding total PRACH
resources that are according to one of the following PRACH configuration
o
Case C1: PRACH
configuration #17 (10ms)
o
Case C2: PRACH
configuration #0 (160ms)
o
Companies to report details
of assumed spatial domain adaptation mechanism, including details of non-uniform PRACH resource allocation across SSBs
§
Setting F: Cat 1/Cat 2 BS
as defined in TR38.864
§
Setting G1: Number of SSB
beams: 4,8 SSBs in a SSB burst with SSB pattern case C
§
Note 1: Baseline to compare
is Case C1 vs Case B1/A1-1/A1-2, Case C2 vs Case B2/A2-1
§
Note 2: It is up to company
to report the SSB-RO mapping ratio and FDMed RO number, etc
§
Note 3: Other PRACH
configuration index with different PRACH format other than format 0 is not
precluded
§
Note 4: Other SSB/SIB1/RACH
periodicity/PRACH resource/configuration assumptions are not precluded (up to
companies to report)
o
Other frameworks for
network energy evaluation are not precluded, e.g. including for FR2.
Final summary in R1-2403777.
Please refer to RP-240170 for detailed scope of
the WI.
[117-R19-NES] – Ajit (Ericsson)
Email discussion on Rel-19 NES enhancement
-
To be used for sharing updates on
online/offline schedule, details on what is to be discussed in online/offline
sessions, tdoc number of the moderator summary for online session, etc
R1-2403869 Discussion of on-demand SSB Scell operation FUTUREWEI
R1-2403896 On-demand SSB SCell operation Tejas Networks Limited
R1-2403960 On-demand SSB SCell operation for eNES Huawei, HiSilicon
R1-2403978 Design of on-demand SSB SCell operation Intel Corporation
R1-2404032 Discussion on on-demand SSB SCell operation Spreadtrum
Communications
R1-2404121 On-demand SSB SCell operation Samsung
R1-2404183 Discussions on on-demand SSB Scell operation vivo
R1-2404223 On-demand SSB SCell Operation Nokia, Nokia Shanghai Bell
R1-2404293 On-demand SSB SCell Operation Apple
R1-2404332 Discussion on on-demand SSB SCell operation InterDigital,
Inc.
R1-2404407 Discussion on on-demand SSB SCell operation CATT
R1-2404433 Discussion on on-demand SSB operation for SCell China
Telecom
R1-2404462 Discussion on on-demand SSB SCell operation CMCC
R1-2404506 On-demand SSB SCell operation Sony
R1-2404560 Discussion on on-demand SSB for NES ZTE, Sanechips
R1-2404577 Discussion on on-demand SSB SCell operation HONOR
R1-2404624 Discussion on on-demand SSB SCell operation Xiaomi
R1-2404648 On-demand SSB Scell operation Quectel
R1-2404689 On-demand SSB SCell Operation Google
R1-2404697 On-demand SSB SCell operation Lenovo
R1-2404757 Discussion on on-demand SSB SCell operation Panasonic
R1-2404779 Discussion on On-demand SSB SCell operation ETRI
R1-2404795 Discussion on on-demand SSB for SCell operation NEC
R1-2404807 Discussion on on-demand SSB SCell operation Fujitsu
R1-2404819 Discussion on On-Demand SSB SCell operation Transsion
Holdings
R1-2404858 Discussion on the enhancement to support on demand SSB
SCell operation OPPO
R1-2404894 On-demand SSB SCell operation LG Electronics
R1-2405048 Discussion on on-demand SSB SCell operation NTT
DOCOMO, INC.
R1-2405070 Discussion on on-demand SSB SCell operation Sharp
R1-2405084 On-demand SSB SCell operation MediaTek Inc.
R1-2405105 On-demand SSB SCell operation Ericsson
R1-2405114 Discussion on On-demand SSB SCell operation ITRI
R1-2405126 Discussion of On-demand SSB SCell operation Mavenir
R1-2405127 Discussion on on-demand SSB SCell operation CAICT
R1-2405161 On-demand SSB operation for Scell Qualcomm
Incorporated
R1-2405201 On-demand SSB for SCell ASUSTeK
R1-2405211 On-demand SSB SCell operation for NES Fraunhofer IIS,
Fraunhofer HHI
R1-2405246 Discussion on on-demand SSB Scell operation CEWiT
R1-2405498 Summary #1 of on-demand SSB for NES Moderator (LG
Electronics)
From Tuesday session
Agreement (Signalling)
For a cell supporting on-demand SSB
SCell operation,
·
Support RRC based signaling to indicate
on-demand SSB transmission on the cell.
·
Support MAC CE based signaling to indicate
on-demand SSB transmission on the cell.
·
FFS: Whether to support DCI based signaling
to indicate on-demand SSB transmission on the cell.
o
This DCI signaling does not provide SCell
activation/deactivation.
o
If supported, details on DCI including
UE-specific or group-common DCI, DCI contents, etc.
·
FFS: Scenarios where the above signalings
are applicable
Agreement (Contents)
(amended as shown in red in Friday session)
For a cell supporting on-demand SSB
SCell operation, at
least the following for on-demand SSB via higher layer signaling is supported.
·
Frequency of the on-demand SSB
·
SSB positions within an on-demand SSB burst
by using signaling similar to ssb-PositionsInBurst
·
Periodicity of the
on-demand SSB
·
FFS: Whether more
than one on-demand SSB configurations can be configured for the cell to UE
·
FFS: Whether the RRC
is newly introduced or existing RRC is reused
R1-2405496 Summary #2 of on-demand SSB for NES Moderator (LG
Electronics)
From Wednesday session
Agreement
- At
least support L1 measurement based on on-demand SSB
- For
L1 measurement based on on-demand SSB, periodic, semi-persistent, [and
aperiodic] L1 measurement reports based on existing CSI framework are
supported.
- FFS
on potential enhancements of CSI report configuration and/or
triggering/activation mechanisms for L1 measurement based on on-demand
SSB.
R1-2405497 Summary #3 of on-demand SSB for NES Moderator (LG
Electronics)
From Thursday session
Agreement
- For SSB burst(s) indicated
by on-demand SSB SCell operation via MAC CE, UE
expects that on-demand SSB burst(s)
is transmitted from time instance A which is
determined as follows.
- Alt 3-1: Time instance A is [the slot boundary
of] the first SSB time domain position [of actually transmitted on-demand
SSB burst] which is T [slots or symbols] after the [slot or symbol] where
UE receives a signalling from gNB to indicate on-demand SSB transmission
- The SSB time domain positions of on-demand SSB
burst are configured by gNB.
- FFS: Details of the value of T (≥ 0)
including possibility of T comprising of multiple components
- Note: The value of T is not less than existing
timeline required for UE’s MAC CE processing for SCell activation
- FFS: Whether the value of T is predefined or
indicated/configured by gNB
- FFS: Details of “the [slot or symbol] where UE
receives a signalling from gNB” or “the [slot or symbol] where UE
transmits HARQ-ACK corresponding to a signalling from gNB to trigger
on-demand SSB”
Above
applies at least for the case where SCell with on demand SSB transmission and
cell with signalling transmission have the same numerology.
R1-2405495 Summary #4 of on-demand SSB for NES Moderator (LG
Electronics)
From Friday session
Agreement
For a cell supporting on-demand SSB SCell operation, at
least the followings for on-demand SSB are known to UE.
·
Sub-carrier spacing of the on-demand SSB
·
Physical Cell ID of the on-demand SSB
·
Location of on-demand SSB burst
·
Downlink transmit power of on-demand SSB
·
FFS: Other parameters
·
FFS: Whether each of above parameters is
configured/indicated explicitly or not
Final summary in R1-2405723.
R1-2403870 Discussion of on-demand SIB1 for idle/inactive mode UEs FUTUREWEI
R1-2403942 Discussion on on-demand SIB1 for eNES Huawei, HiSilicon
R1-2403979 Study on on-demand SIB1 for Idle/inactive mode Ues Intel
Corporation
R1-2404033 Discussion on on-demand SIB1 for idle/inactive mode UEs Spreadtrum
Communications
R1-2404122 On-demand SIB1 for idle/inactive mode UEs Samsung
R1-2405363 Discussions on on-demand SIB1 for idle/inactive mode UEs vivo (rev
of R1-2404184)
R1-2404224 On-demand SIB1 for Idle/Inactive mode UEs Nokia,
Nokia Shanghai Bell
R1-2404294 On on-demand SIB1 for IDLE/INACTIVE mode UE Apple
R1-2404333 Discussion on on-demand SIB1 for idle/inactive mode UEs InterDigital,
Inc.
R1-2404408 Discussion on on-demand SIB1 CATT
R1-2404434 Discussion on on-demand SIB1 for idle/inactive mode UEs China
Telecom
R1-2404463 Discussion on on-demand SIB1 for UEs in idle/inactive mode CMCC
R1-2404507 On-demand SIB1 for idle/inactive mode UEs Sony
R1-2404561 Discussion on on-demand SIB1 for UEs ZTE, Sanechips
R1-2404625 Discussion on on-demand SIB1 for idle/inactive mode UEs Xiaomi
R1-2404690 On-demand SIB1 for Idle/Inactive Mode UE Google
R1-2404698 On-demand SIB1 for idle/inactive mode UEs Lenovo
R1-2404758 Discussion on on-demand SIB1 for idle/inactive mode UEs Panasonic
R1-2404780 On-demand SIB1 for idle/inactive mode UEs for NES ETRI
R1-2404796 Discussion on on-demand SIB1 for UEs in idle/inactive mode NEC
R1-2404800 Discussion on on-demand SIB1 for idle/inactive mode UEs DENSO
CORPORATION
R1-2404808 Discussion on on-demand SIB1 transmission for idle/inactive
mode UEs Fujitsu
R1-2404820 Discussion on on-demand SIB1 transmission for idle/inactive
mode UEs Transsion Holdings
R1-2404859 Discussion on the enhancement to support on demand SIB1 for
idle/inactive mode UE OPPO
R1-2404895 On-demand SIB1 for idle/inactive mode UEs LG
Electronics
R1-2405049 Discussion on on-demand SIB1 for idle/inactive mode UEs NTT
DOCOMO, INC.
R1-2405071 Discussion on on-demand SIB1 transmission for idle UEs Sharp
R1-2405341 On-demand SIB1 for idle or inactive mode UEs MediaTek
Inc. (rev of R1-2405085)
R1-2405106 Study of on-demand SIB1 for UEs in idle/inactive mode for
NES Ericsson
R1-2405162 On-demand SIB1 procedure Qualcomm Incorporated
R1-2405177 Discussion on on-demand SIB1 for idle/inactive mode UEs KT
Corp.
R1-2405182 On-demand SIB1 for Idle/Inactive mode UEs III
R1-2405202 Triggering of on-demand SIB1 ASUSTeK
R1-2405595 On-demand SIB1 for NES Fraunhofer IIS, Fraunhofer HHI (rev
of R1-2405207)
R1-2405213 Views on On-demand SIB1 operation for idle/inactive UEs Vodafone
R1-2405247 Discussion on on-demand SIB1 CEWiT
R1-2405370 FL summary 1 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Tuesday session
Agreement
For
SIB1 in idle/inactive mode, prioritize RAN1 discussions on Case 2 and Case 3
·
Case 2 (Option 1+B+X) is feasible from RAN1 perspective.
·
Further study Case 3, focusing on the
additional NES benefits over Case 2, feasibility, complexity, and spec impact.
Agreement
For
further study of on-demand SIB1 in idle/inactive mode, it is assumed that
always-on SSB is transmitted on the NES cell with on-demand SIB1.
Agreement
At
least for Case-2: For
further study of type 0 PDCCH monitoring occasions for on demand SIB1, after UE transmits the
UL WUS in
idle/inactive mode, RAN1 assumes following as a starting point:
- Option
1: One or more type 0 PDCCH monitoring occasions for on demand SIB1 within
a time window
- FFS:
How the search space zero configuration is provided (e.g. from searchSpaceZero
in MIB or from a new search space that is indicated by UL-WUS
configuration)
- FFS:
Details of the time window, including at least the starting time and
duration
- FFS:
Whether/how to support transmission of on-demand SIB1 with the
association with SSB(s) based on a received UL-WUS
R1-2405371 FL summary 2 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Wednesday session
Agreement
From RAN1 point of view, the following is
feasible. It is up to RAN2 to decide whether/how to support it.
At least for Case 2 (Option 1+B+X) design,
a unified configuration format that can support both Option 2 (i.e. a UL-WUS
configuration applies to multiple NES cells) and Option 3 (i.e. a UL-WUS
configuration applies to a single NES cell).
Agreement
For further study of on-demand SIB1 in
idle/inactive mode, on the spatial relationships among PDCCH/PDSCH of on-demand
SIB1, SSB, and UL WUS, as UL WUS is using dedicated PRACH resource, it is
assumed that spatial relationships among PDCCH/PDSCH of on-demand SIB1, SSB and
UL WUS can follow legacy mechanism.
Agreement
For further study of on-demand SIB1 in
idle/inactive mode, use the following Table I (from R1-2405106, Ericsson) as a starting point to discuss the required
parameters/contents inside the UL WUS configuration.
Table
I.
|
Purpose
|
Parameters
|
|
To
which cell does the config applies
|
NES-CellId
|
PhysCellId
|
|
ARFCN-ValueNR
|
|
WUS
transmission
|
SIB1-RequestConfig
|
ss-PBCH-BlockPower
|
|
rach-OccasionsSIB1
|
Prach-ConfigurationIndex
|
|
msg1-FDM
|
|
msg1-FrequencyStart
|
|
zeroCorrelationZoneConfig
|
|
preambleReceivedTargetPower
|
|
preambleTransMax
|
|
powerRampingStep
|
|
ra-ResponseWindow
|
|
ssb-perRACH-Occasion
|
|
sib1-RequestPeriod
|
|
sib1-RequestResource
|
ra-PreambleStartIndex
|
|
ra-AssociationPeriodIndex
|
|
ra-ssb-OccasionMaskIndex
|
|
rsrp-ThresholdSSB
|
|
prach-RootSequenceIndex
|
|
msg1-SubcarrierSpacing
|
|
restrictedSetConfig
|
|
tdd-UL-DL-ConfigurationCommon
|
|
frequencyInfoUL
|
frequencyBandList
|
|
absoluteFrequencyPointA
|
|
offsetToCarrier
|
|
p-Max
|
|
frequencyShift7p5khz
|
|
SIB1
reception
|
pdcch-ConfigSIB1
|
ssb-SubcarrierOffset
|
|
controlResourceSetZero
|
|
searchSpaceZero
|
|
RAR
Reception
|
pdcch-ConfigOD-SIB1-RAR
|
controlResourceSet
|
|
monitoringSlotPeriodicityAndOffset
|
|
Duration
|
|
monitoringSymbolsWithinSlot
|
|
aggregationLevels
|
R1-2405372 FL summary 3 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
R1-2405373 FL summary 4 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Thursday session
Agreement
For
the evaluation of achievable NES gain on NES cell with on-demand SIB1 in
idle/inactive mode, the following is observed with 20ms SSB period and 20ms
SIB1 period (Case A), FR1, empty load
- For
Cat 1 BS, 8 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 39.37% - 47.69% from the following 7 sources
- One
source (R1-2405162) reports 25% NES
gain with PRACH configuration index = 152
- One
source (R1-2403979) reports the
following NES gain with PRACH configuration index = 98
- 24.6%
with one beam of SIB1 PDSCH transmitted in each slot
- 17.4%
with two beams of SIB1 PDSCH transmitted in each slot
- One
source (R1-2404122) reports the
following with FDMed SSB and PDSCH of SIB1
§
9.27%~18.94%
NES gain with UL WUS configuration transmitted in legacy SIB on Cell A
§
0%~9.66%
NES gain with UL WUS configuration transmitted in separated SIB on Cell A. The
separated SIB is
TDMed with legacy SIB and transmitted in a 20ms period using dedicated
resource.
§
0%
NES gain with Case 1 (Options 1+A+X) and WUS configuration transmitted in
separate SIB on the NES cell
§
13.25%
NES gain with Case 1 (Options 1+A+X) and pre-configured for fixed WUS
configuration
·
NES
cell does not transmit the WUS configuration
- For
Cat 1 BS, 4 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 22.1% - 42.6% from the following 5 sources
- One
source (R1-2403979) reports the
following NES gain with PRACH configuration index = 98
- 16.8%
with one beam of SIB1 PDSCH transmitted in each slot
- 10.9%
with two beams of SIB1 PDSCH transmitted in each slot
- For
Cat 1 BS, 8 beams, 0% < on-demand SIB1 transmission rate <= 30%,
- the
NES gain is 30.43% - 45.79% from the following 4 sources
- One
source (R1-2405162) reports the
following NES gain with PRACH configuration index = 152
- 25%
NES gain with Case 3 (Options 2+B+Y) assuming the UE can camp on the NES
cell and the SIB1 is only transmitted in a single beam corresponding to
the UL WUS beam
- 23%
with Case 2 (Options 1+B+X)
- For
Cat 1 BS, 4 beams, 0% < on-demand SIB1 transmission rate <= 30%,
- the
NES gain is 21.79% - 33.11% from the following 2 sources
- For
Cat 2 BS, 8 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 20.5% - 39.34% from the following 8 sources
- One
source (R1-2404224) reports 11.9%
NES gain with medium cell load on Cell A
- For
Cat 2 BS, 4 beams, 0% on-demand SIB1 transmission rate, the NES gain is
19.31 – 19.39% from one source (R1-2405341)
- For
Cat 2 BS, 8 beams, 0%
< on-demand SIB1 transmission rate <= 30%,
- the
NES gain is 29.19% - 36.87% from the following 3 sources
- One
source (R1-2404561) reports
15.87%~20.18% NES gain with PRACH configuration index = 148
- For
Cat 1 BS, 4/8 beams, 4% < on-demand
SIB1 transmission rate < 24%, the NES gain is 17.98%~24.48% from
one source (R1-2404408).
Agreement
For
the evaluation of achievable NES gain on NES cell with on-demand SIB1 in
idle/inactive mode, the following is observed with 20ms SSB period and 160ms
SIB1 period (Case C), FR1, empty load
- For
Cat 1 BS, 8 beams, 0% on-demand SIB1 transmission rate, the NES gain is
2.21 – 10.6% from the following 10 sources
- For
Cat 1 BS, 4 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 1.7% - 6.23% from the following 5 sources
- One
source (R1-2404758) reports 28.9%
NES gain with Case 3 where no PRACH and paging is activated for the NES
cell
- For
Cat 1 BS, 8 beams, 0% < on-demand SIB1 transmission rate <= 30%, the
NES gain is 1.75% - 8.48% from the following 6 sources
- For
Cat 1 BS, 4 beams, 0% < on-demand SIB1 transmission rate <= 30%, the
NES gain is 1.01% - 5.8% from the following 3 sources
- For
Cat 2 BS, 8 beams, 0% on-demand SIB1 transmission rate, the NES gain is
3.24% - 7.76% from the following 5 sources
- For
Cat 2 BS, 4 beams, 0% on-demand SIB1 transmission rate, the NES gain is
2.96% from one source (R1-2405341)
- For
Cat 2 BS, 8 beams, 0%
< on-demand SIB1 transmission rate <= 30%, the NES gain is 2.5% - 7.44%
from
the following 3 sources
Agreement
For
the evaluation of achievable NES gain on NES cell with on-demand SIB1 in
idle/inactive mode, the following is observed with 20ms SSB period and 20ms
SIB1 period (Case A), FR1, low load
- For
Cat 1 BS, 8 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 30.56% - 41.8% from the following 5 sources
- One
source (R1-2403979) reports the
following NES gain with PRACH configuration index = 98
- 13.9%
with one beam of SIB1 PDSCH transmitted in each slot
- 7.9%
with two beams of SIB1 PDSCH transmitted in each slot
- For
Cat 1 BS, 4 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 16% - 36.2% from the following 5 sources
- One
source (R1-2404033) reports 10% NES
gain with FDMed SSB and PDSCH of SIB1
- One
source (R1-2403979) reports the
following NES gain with PRACH configuration index = 98
- 5.2%
with one beam of SIB1 PDSCH transmitted in each slot
- 1.9%
with two beams of SIB1 PDSCH transmitted in each slot
- For
Cat 1 BS, 8 beams, 0% < on-demand SIB1 transmission rate <= 30%,
- the
NES gain is 22.44% - 37.64% from the following 3 sources
- One
source (R1-2404122) reports the
following with FDMed SSB and PDSCH of SIB1
§
4.73%~9.64%
NES gain with UL WUS configuration transmitted in legacy SIB on Cell A
§
0%~4.8%
NES gain with UL WUS configuration transmitted in separated SIB on Cell A. The
separated SIB is
TDMed with legacy SIB and transmitted in a 20ms period using dedicated
resource.
§
0%
NES gain with Case 1 (Options 1+A+X) and WUS configuration transmitted in
separate SIB on the NES cell
§
7%
NES gain with Case 1 (Options 1+A+X) and pre-configured for fixed WUS
configuration
·
NES
cell does not transmit the WUS configuration
- For
Cat 1 BS, 4 beams, 0% < on-demand SIB1 transmission rate <= 30%,
- the
NES gain is 13.17% - 36.2% from the following 3 sources
- For
Cat 2 BS, 8 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 16.8% - 28.77% from the following 6 sources
- One
source (R1-2404224) reports 10.5%
NES gain with medium cell load on Cell A
- For
Cat 2 BS, 4 beams, 0% on-demand SIB1 transmission rate, the NES gain is
12.71% – 12.88% from one source (R1-2405341)
- For
Cat 2 BS, 8 beams, 0%
< on-demand SIB1 transmission rate <= 30%, the NES gain is 14.43% -
27.47% from
the following 3 sources
Agreement
For
the evaluation of achievable NES gain on NES cell with on-demand SIB1 in
idle/inactive mode, the following is observed with 20ms SSB period and 160ms
SIB1 period (Case C), FR1, low load
- For
Cat 1 BS, 8 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 1.2 – 8.3% from the following 7 sources
- For
Cat 1 BS, 4 beams, 0% on-demand SIB1 transmission rate, the NES gain is
0.2% - 5.46% from the following 4 sources
- For
Cat 1 BS, 8 beams, 0% < on-demand SIB1 transmission rate <= 30%, the
NES gain is 2.87% - 7.38% from the following 4 sources
- For
Cat 1 BS, 4 beams, 0% < on-demand SIB1 transmission rate <= 30%, the
NES gain is 1.97% - 4.48% from the following 2 sources
- For
Cat 2 BS, 8 beams, 0% on-demand SIB1 transmission rate, the NES gain is
3.04% - 5.57% from the following 4 sources
- For
Cat 2 BS, 4 beams, 0% on-demand SIB1 transmission rate, the NES gain is
1.79% from one source (R1-2405341)
- For
Cat 2 BS, 8 beams, 0%
< on-demand SIB1 transmission rate <= 30%, the NES gain is 2.12% -
5.26% from
the following 3 sources
Agreement
For
the evaluation of achievable NES gain on NES cell with on-demand SIB1 in
idle/inactive mode, the following is observed with 20ms SSB period and 20ms
SIB1 period (Case A), FR1, medium load
- For
Cat 1 BS, 8 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 9.88% - 14.4% from the following 2 sources
- One
source (R1-2403979) reports the
following NES gain with PRACH configuration index = 98
- 4.5%
with one beam of SIB1 PDSCH transmitted in each slot
- 2.3%
with two beams of SIB1 PDSCH transmitted in each slot
- For
Cat 1 BS, 4 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 4.92% - 8.4% from the following 2 sources
- One
source (R1-2403979) reports the
following NES gain with PRACH configuration index = 98
- 1.5%
with one beam of SIB1 PDSCH transmitted in each slot
- 0.5%
with two beams of SIB1 PDSCH transmitted in each slot
- For
Cat 1 BS, 8 beams, 0% < on-demand SIB1 transmission rate <= 30%,
- the
NES gain is 11.5% - 12.88% from one source (R1-2405363)
- One
source (R1-2404122) reports the
following with FDMed SSB and PDSCH of SIB1
§
1.94%~4%
NES gain with UL WUS configuration transmitted in legacy SIB on Cell A
§
0%~1.94%
NES gain with UL WUS configuration transmitted in separated SIB on Cell A. The
separated SIB is
TDMed with legacy SIB and transmitted in a 20ms period using dedicated
resource.
§
0%
NES gain with Case 1 (Options 1+A+X) and WUS configuration transmitted in
separate SIB on the NES cell
§
2.64%
NES gain with Case 1 (Options 1+A+X) and pre-configured for fixed WUS
configuration
·
NES
cell does not transmit the WUS configuration
- For
Cat 1 BS, 4 beams, 0% < on-demand SIB1 transmission rate <= 30%, the
NES gain is 6%~7.53% from one source (R1-2405363)
- For
Cat 2 BS, 8 beams, 0% on-demand SIB1 transmission rate, the NES gain is
8.08% - 15.47% from the following 4 sources
- For
Cat 2 BS, 4 beams, 0% on-demand SIB1 transmission rate, the NES gain is
4.09% – 4.19% from one source (R1-2405341)
- For
Cat 2 BS, 8 beams, 0%
< on-demand SIB1 transmission rate <= 30%, the NES gain is 10.78% -
15.3% from
the following 2 sources
Agreement
For
the evaluation of achievable NES gain on NES cell with on-demand SIB1 in
idle/inactive mode, the following is observed with 20ms SSB period and 160ms
SIB1 period (Case C), FR1, medium load
- For
Cat 1 BS, 8 beams, 0% on-demand SIB1 transmission rate, the NES gain is
0.3 – 2.44% from the following 4 sources
- For
Cat 1 BS, 4 beams, 0% on-demand SIB1 transmission rate, the NES gain is
0.1% - 1.3% from the following 3 sources
- For
Cat 1 BS, 8 beams, 0% < on-demand SIB1 transmission rate <= 30%, the
NES gain is 1.24% - 2.26% from the following 2 sources
- For
Cat 1 BS, 4 beams, 0% < on-demand SIB1 transmission rate <= 30%, the
NES gain is 0.67% - 1.6% from one source (R1-2405363)
- For
Cat 2 BS, 8 beams, 0% on-demand SIB1 transmission rate, the NES gain is
0.95% - 4.13% from the following 3 sources
- For
Cat 2 BS, 4 beams, 0% on-demand SIB1 transmission rate, the NES gain is
0.48% from one source (R1-2405341)
- For
Cat 2 BS, 8 beams, 0%
< on-demand SIB1 transmission rate <= 30%, the NES gain is 1.44% -
4.02% from
the following 2 sources
Agreement
For
the evaluation of achievable NES gain on NES cell with on-demand SIB1 in
idle/inactive mode, the following is observed with 20ms SSB period and 40ms
SIB1 period (Case D), FR1, empty load
- For
Cat 1 BS, 8 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 24.51% - 31.3% from the following 6 sources
- One
source (R1-2403979) reports the
following NES gain with PRACH configuration index = 98
- 16.3%
with one beam of SIB1 PDSCH transmitted in each slot
- 10.6%
with two beams of SIB1 PDSCH transmitted in each slot
- For
Cat 1 BS, 4 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 12.4% - 35.5% from the following 5 sources
- One
source (R1-2403979) reports the
following NES gain with PRACH configuration index = 98
- 10.1%
with one beam of SIB1 PDSCH transmitted in each slot
- 6.1%
with two beams of SIB1 PDSCH transmitted in each slot
- For
Cat 1 BS, 8 beams, 0% < on-demand SIB1 transmission rate <= 30%, the
NES gain is 19.44% - 28.81% from the following 3 sources
- For
Cat 1 BS, 4 beams, 0% < on-demand SIB1 transmission rate <= 30%, the
NES gain is 12.87% - 20.09% from the following 2 sources
- For
Cat 2 BS, 8 beams, 0% on-demand SIB1 transmission rate, the NES gain is
11.77% - 25.46% from the following 5 sources
- For
Cat 2 BS, 4 beams, 0% on-demand SIB1 transmission rate, the NES gain is
10.69 – 10.74% from one source (R1-2405341)
- For
Cat 2 BS, 8 beams, 0%
< on-demand SIB1 transmission rate <= 30%,
- the
NES gain is 16.46% - 24.24% from the following 2 sources
- One
source (R1-2404561) reports
8.92%~10.37% NES gain with PRACH configuration index = 148
Agreement
For
the evaluation of achievable NES gain on NES cell with on-demand SIB1 in
idle/inactive mode, the following is observed with 20ms SSB period and 40ms
SIB1 period (Case D), FR1, low load
- For
Cat 1 BS, 8 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 18.38% - 26.4% from the following 5 sources
- One
source (R1-2403979) reports the
following NES gain with PRACH configuration index = 98
- 8.1%
with one beam of SIB1 PDSCH transmitted in each slot
- 4.3%
with two beams of SIB1 PDSCH transmitted in each slot
- For
Cat 1 BS, 4 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 9.84% - 17.41% from the following 3 sources
- One
source (R1-2403979) reports the
following NES gain with PRACH configuration index = 98
- 2.8%
with one beam of SIB1 PDSCH transmitted in each slot
- 1%
with two beams of SIB1 PDSCH transmitted in each slot
- For
Cat 1 BS, 8 beams, 0% < on-demand SIB1 transmission rate <= 30%, the
NES gain is 13.36% - 23.68% from the following 3 sources
- For
Cat 1 BS, 4 beams, 0% < on-demand SIB1 transmission rate <= 30%, the
NES gain is 7.27% - 15.59% from the following 2 sources
- For
Cat 2 BS, 8 beams, 0% on-demand SIB1 transmission rate, the NES gain is
10.48% - 17.72% from the following 4 sources
- For
Cat 2 BS, 4 beams, 0% on-demand SIB1 transmission rate, the NES gain is
7.01% from one source (R1-2405341)
- For
Cat 2 BS, 8 beams, 0%
< on-demand SIB1 transmission rate <= 30%, the NES gain is 7.7% -
17.05% from
the following 3 sources
Agreement
For
the evaluation of achievable NES gain on NES cell with on-demand SIB1 in
idle/inactive mode, the following is observed with 20ms SSB period and 40ms
SIB1 period (Case D), FR1, medium load
- For
Cat 1 BS, 8 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 5.07% - 7.8% from the following 2 sources
- One
source (R1-2403979) reports the
following NES gain with PRACH configuration index = 98
- 2.4%
with one beam of SIB1 PDSCH transmitted in each slot
- 1.2%
with two beams of SIB1 PDSCH transmitted in each slot
- For
Cat 1 BS, 4 beams, 0% on-demand SIB1 transmission rate,
- the
NES gain is 2.46% - 4.4% from the following 2 sources
- One
source (R1-2403979) reports the
following NES gain with PRACH configuration index = 98
- 0.7%
with one beam of SIB1 PDSCH transmitted in each slot
- 0.3%
with two beams of SIB1 PDSCH transmitted in each slot
- For
Cat 1 BS, 8 beams, 0% < on-demand SIB1 transmission rate <= 30%, the
NES gain is 5.62~7.01% from one source (R1-2405363)
- For
Cat 1 BS, 4 beams, 0% < on-demand SIB1 transmission rate <= 30%, the
NES gain is 2.77% - 3.85% from one source (R1-2405363)
- For
Cat 2 BS, 8 beams, 0% on-demand SIB1 transmission rate, the NES gain is
4.08%~10.1% from the following 3 sources
- For
Cat 2 BS, 4 beams, 0% on-demand SIB1 transmission rate, the NES gain is
2.02%~2.09% from one source (R1-2405341)
- For
Cat 2 BS, 8 beams, 0%
< on-demand SIB1 transmission rate <= 30%, the NES gain is 5.61% -
9.94% from
the following 2 sources
Agreement
For
the evaluation of NES loss on cell A, the following is observed
- NES
loss of 0%~0.98% from the following 15 sources with UL WUS configuration
transmitted in legacy SIB on Cell A (with different assumptions on SIB
periodicity and cell loading):
- R1-2404408, R1-2404463, R1-2403942, R1-2403979, R1-2405341, R1-2404224, R1-2404859, R1-2404758, R1-2405162, R1-2404122, R1-2404507, R1-2404033, R1-2405363, R1-2404625, R1-2404561 (for Case 2)
- One
source (R1-2405106) reports for the
case with UL WUS configuration transmitted in separated SIB on Cell A
where the separated SIB is TDMed with legacy SIB and transmitted in a
320ms period using dedicated resource.
- 0.62%~2.65%
NES loss for Case 2 (Options 1+B+X) with empty load
- 0.73%~3.20%
NES loss for Case 3 (Options 2+B+Y) with empty load
- One
source (R1-2404122) reports
- 2.95%(medium
load)~15.49%(empty load) NES loss with UL WUS configuration transmitted
in separated SIB on Cell A
- The
separated SIB is
TDMed with legacy SIB and transmitted in a 20ms period using dedicated
resource.
- 1.28%(medium
load)~3.62%(empty load) NES loss with UL WUS configuration transmitted in
legacy SIB on Cell A
Conclusion
For
further study of on-demand SIB1 in idle/inactive mode, enabling or disabling
specific operations (e.g. paging, RACH receiving, OSI request …) of the NES
cell with on-demand SIB1 is up to RAN2.
R1-2405632 FL summary 5 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Friday session
Agreement
For
the evaluation of achievable NES gain on NES cell with on-demand SIB1 in
idle/inactive mode, the following is observed with 20ms SSB period and 20ms
SIB1 period (Case A), FR1, 8 beams, on-demand SIB1 transmission rate > 30%
· For Cat 1 BS, empty load, the NES gain is
37.77% from one source (R1-2404463)
· For Cat 2 BS, empty load,
o
the NES gain is 8.9% -
28.71% from the following 3 sources
§
R1-2404224, R1-2404561, R1-2404463
o
The NES gain is 1.47% from
one source (R1-2404561) with 75% on-demand SIB1 transmission rate
·
For Cat 2 BS, low load,
o
the NES gain is 7.9% -
14.65% from the following 2 sources
§
R1-2404224, R1-2404561
o
The NES gain is 0.42% from
one source (R1-2404561) with 75% on-demand SIB1 transmission rate
·
For Cat 2 BS, medium load,
o
the NES gain is 6.2% -
10.4% from the following 2 sources
§
R1-2404224, R1-2404561
o
The NES gain is 0.12% from
one source (R1-2404561) with 75% on-demand SIB1 transmission rate
Agreement
For
the evaluation of achievable NES gain on NES cell with on-demand SIB1 in
idle/inactive mode, the following is observed with 20ms SSB period and 40ms
SIB1 period (Case D), FR1, 8 beams, on-demand SIB1 transmission rate > 30%
·
For Cat 2 BS,
empty/low/medium load, the NES gain is 3.77% - 5.97% from one source (R1-2404561)
Agreement
For
the evaluation of achievable NES gain on NES cell with on-demand SIB1 in
idle/inactive mode, the following is observed with 20ms SSB period and 160ms
SIB1 period (Case C), FR1, 8 beams, on-demand SIB1 transmission rate > 30%
·
For Cat 1/Cat 2 BS,
empty/low/medium load, the NES gain is 0.31%~3.33% from the following 2 sources
o
R1-2404561, R1-2404122
Agreement
For
the evaluation of the energy consumption to transmit WUS configuration on NES
Cell:
·
One source (R1-2405595) reports that for broadcasting WUS configuration using DCI
occupying 2 symbols per SSB beam) on NES cell every 80 ms on CORESET#0 (48
RBs):
o
For BS category 1,
empty/low load, the energy consumption is increased by 6.26%~8.51% over SSB
transmission only. The energy saving gain with Case 1 is 40.52% / 32.41% for empty/low load over the baseline
with 8 beams, SIB-1 period 20ms (baseline), 0% SIB-1 transmission rate (for on
demand SIB1).
o
For BS category 2,
empty/low load, the energy consumption is increased by 1.55%~2.11% over SSB
transmission only. The energy saving gain with Case 1 is 28.25% / 23.03% for empty/low load over the baseline
with 8 beams, SIB-1 period 20ms (baseline), 0% SIB-1 transmission rate (for on
demand SIB1).
For
future meetings:
Companies
are encouraged to check section 3 of R1-2405632 for discussion on RAN1 / RAN2
workscope.
R1-2405658 FL summary 6 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
R1-2403871 Discussion of the adaptation of common signal/channel
transmissions FUTUREWEI
R1-2403895 Adaptation of common signal/channel transmissions Tejas
Networks Limited
R1-2403943 On common channel/signal adaptation for eNES Huawei,
HiSilicon
R1-2403980 Adaptation of common signal/channel transmissions for
Network Energy Saving Intel Corporation
R1-2404034 Discussion on adaptation of common signal/channel
transmissions Spreadtrum Communications
R1-2404123 Adaptation of common signal/channel transmissions Samsung
R1-2404185 Discussions on adaptation of common signal/channel
transmissions vivo
R1-2404225 Adaptation of common signal/channel transmissions Nokia,
Nokia Shanghai Bell
R1-2404295 On adaptation of common signal/channel for NES enhancements Apple
R1-2404334 Discussion on adaptation of common signal/channel
transmissions InterDigital, Inc.
R1-2404409 Discussion on adaptation of common signal/channel
transmissions CATT
R1-2404464 Discussion on adaptation of common signal/channel
transmissions CMCC
R1-2404489 Adaptation of common signals and channels Lenovo
R1-2404508 Adaptation of common signal/channel transmissions Sony
R1-2404562 Discussion on common signal channel for NES ZTE,
Sanechips
R1-2404578 Discussion on adaptation of common signal channel
transmissions HONOR
R1-2404626 Discussion on adaptation of common signal and channel
transmissions Xiaomi
R1-2404691 Adaptation of Common Signals Google
R1-2404759 Discussion on adaptation of common signal/channel
transmission Panasonic
R1-2404781 Adaptation of common signal/channel transmissions for NES ETRI
R1-2404797 Discussion on adaptation of common signal/channel
transmissions for Cell DTX/DRX NEC
R1-2404809 Discussion on adaptation of common signal / channel
transmissions Fujitsu
R1-2404821 Discussion on adaptive transmission of common signal or
common channel Transsion Holdings
R1-2404860 Discussion on adaptation of common signal/channel
transmission OPPO
R1-2404896 Adaptation of common signal/channel transmissions LG
Electronics
R1-2405050 Discussion on adaptation of common signal/channel
transmissions NTT DOCOMO, INC.
R1-2405072 Discussion on adaptation of common signal/channel
transmissions Sharp
R1-2405086 Adaptation of common signal/channel transmissions MediaTek
Inc.
R1-2405107 Adaptation of common signal/channel transmissions for NES Ericsson
R1-2405128 Adaptation of Common Signal Channel Transmissions Mavenir
R1-2405163 Adaptation of common channel transmissions Qualcomm
Incorporated
R1-2405179 Discussion on adaptation of common signal/channel
transmissions KT Corp.
R1-2405209 Adaptation of Common Signals and Channels for NES Fraunhofer
IIS, Fraunhofer HHI
R1-2405248 Discussion on adaptation of common signal and channel
transmissions CEWiT
R1-2405459 Summary#1 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
Presented
in Tuesday session.
R1-2405460 Summary#2 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From
Wednesday session
Agreement
(modified as shown in red in Thursday session
For
adaptation of PRACH in time-domain, support at least the following case(s)
- Case
1: no time-domain overlap between the additional PRACH resources for
NES-capable UEs and the PRACH resources for legacy UEs
- Case
2: time-domain overlap but no overlap in frequency domain between the
additional PRACH resources for NES-capable UEs and the PRACH resources for
legacy UEs
- Case
3: additional PRACH resources for NES-capable UEs and legacy PRACH
resources overlap neither in time nor frequency domains
- FFS:
whether additional conditions are needed to support the above cases
- FFS:
Additional case whether full/partial overlap in both time and frequency is
allowed
- Above
does not preclude discussion for the case
where the configuration
of for additional PRACH resources contains
legacy PRACH resources
Agreement
At
least for the case where legacy ROs and additional ROs overlap in neither time
nor frequency domain, for adaptation of PRACH in time-domain, the SSB-RO mapping
rule for additional PRACH resources follows the legacy SSB-RO mapping rule.
- Mapping SS/PBCH
block indexes to valid additional PRACH occasions provided by semi-static
signalling follows the legacy mapping order for preamble/time
resource/frequency/PRACH slot indexes.
- Note: This mapping
is not impacted by time domain PRACH adaptation
- Validation rules
for the additional PRACH resources follow the legacy validation rules for
PRACH resources configured for legacy UEs.
R1-2405630 Summary#3 of AI
9.5.3 for R19 NES Moderator (Ericsson)
From
Thursday session
Agreement
For
the study of adaptation of PRACH in spatial domain, following network energy
savings gains were reported by sources based on the evaluation framework agreed
in RAN1#116bis:
- Two sources showed
following NES gain for TDD, CAT1 BS power model, case C1 vs A1-1, zero
load [R1-2404409, R1-2405107]
- Seven sources showed following NES gain for TDD, CAT1 BS
power model, case C1 vs B1/A1-2, zero load [R1-2404225, R1-2404185, R1-2404334, R1-2404123, R1-2404562, R1-2405107, R1-2405163]
- 0% ~ 31%
- Note: Five sources
assumed that case B1 has same PRACH resources as case A1-2. Remaining two
sources evaluated only A1-2.
- Note: Three
sources showed NES gains 0% ~ 10% [R1-2404225, R1-2404185, R1-2404334]
- One source showed following NES gain for TDD, CAT1 BS power
model, case C1 vs B1, zero load [R1-2404464]
- 1.0%~8.8%
- Note: The
evaluation results provide the extra NES gain of spatial domain PRACH
adaptation compared to time domain PRACH adaptation, where spatial domain and time domain PRACH adaptations are based on dynamic
switching between PRACH resources according to two PRACH configuration
indexes.
- One source showed following NES gain for TDD, CAT1 BS power
model, case C1 vs B1, zero load [R1-2404626]
- -48.41%~0%
- Note: For B1, it was assumed
that periodicity of PRACH resources can be adapted. For C1, it was
assumed that periodicity of PRACH resources is not adapted and some ROs
within a periodicity can be deactivated.
- One source showed
following NES gain for TDD, CAT1 BS power model, for case C1 vs A1-2, zero
load [R1-2404626]
- 4.59%~38.04%
- Note: For C1, it was assumed
that periodicity of PRACH resources is not adapted and some ROs within a
periodicity can be deactivated.
- Four sources showed following NES gain for TDD, CAT2 BS power
model, case C1 vs B1/A1-2, zero load [R1-2404562, R1-2404225, R1-2403943, R1-2404626]
- 0% ~ 3.5%
- Note: Three
sources assumed that case B1 has same PRACH resources as case A1-2. One
source evaluated only A1-2.
- One source showed following NES gain for TDD, CAT2 BS power
model, case C1 vs B1, zero load [R1-2404464]
- 0%~0.2%
- Note: The
evaluation results provide the extra NES gain of spatial domain PRACH
adaptation compared to time domain PRACH adaptation, where spatial domain and time domain PRACH adaptations are based on dynamic
switching between PRACH resources according to two PRACH configuration
indexes
- One source showed following NES gain for TDD, CAT2 BS power
model, case C1 vs B1, zero load [R1-2404626]
- -1.19%~0%
- Note: For B1, it was assumed
that periodicity of PRACH resources can be adapted. For C1, it was
assumed that periodicity of PRACH resources is not adapted and some ROs
within a periodicity can be deactivated.
- Two sources showed
following NES gain for TDD, CAT1 or CAT2 BS power model, case C2 vs B2,
zero load [R1-2403943, R1-2405107]
- One source showed following
NES gain for TDD, CAT1 BS power model, (C1 vs A1-2 with changed PRACH
format), PRACH format A, 10ms PRACH periodicity, different loads [R1-2403980]
- 13.7%/8.7%/4.9%/2.6% for
zero/low/light/medium cell load
- One source showed following
NES gain for TDD, CAT1 BS power model, (C1 vs B1 with changed PRACH
format), PRACH format A, 10ms PRACH periodicity, different loads [R1-2403980]
- 8.03%/5.1%/3.06%/1.74% for
zero/low/light/medium cell load
- One source showed
following NES gain for TDD, C1 vs B1/A1-2, different loads [R1-2404562]
- 16%/4.78% for
light/medium cell load for CAT1 BS power model
- 0.65%/0.29% for
light/medium cell load for CAT2 BS power model
- One source showed following
NES gain for TDD, C1 vs B1, different loads [R1-2404626]
- -18.57%~0%/-2.52%~0% for low
/medium cell load for CAT1 BS power model
- -0.81%~0%/-0.42%~0% for low
/medium cell load for CAT2 BS power model
- Note: For B1, it was assumed
that periodicity of PRACH resources can be adapted. For C1, it was
assumed that periodicity of PRACH resources is not adapted and some ROs
within a periodicity can be deactivated.
- One source showed following
NES gain for TDD, C1 vs A1-2, different loads [R1-2404626]
- 3.67%~19.88%/2.29%~5.22% for
low /medium cell load for CAT1 BS power model
- 0.67%~1.75%/0.39%~0.91% for
low /medium cell load for CAT2 BS power model
- Note: For C1, it was assumed
that periodicity of PRACH resources is not adapted and some ROs within a
periodicity can be deactivated.
- One source showed
NES gain for FDD, C1 vs B1, zero load [R1-2404464]
- 1.4%~7% for CAT1
BS power model
- 0%~0.3% for CAT2
BS power model
- Note: The
evaluation results provide the extra NES gain of spatial domain PRACH
adaptation compared to time domain PRACH adaptation, where spatial domain and time domain PRACH adaptations are based on dynamic
switching between PRACH resources according to two PRACH configuration
indexes
- One source showed
NES gain for FR2, CAT1 BS power model, spatial domain adaptation of PRACH
configuration index 75 vs a time domain adaptation of PRACH configuration
index 75, zero load [R1-2405163]
- Note 1: About
possibility of scenarios with non-uniform distribution of UEs in different
beams
o Several companies
indicated (and three companies showed data/analysis) that there can be
scenarios with non-uniform distribution of UEs in different beams.
o Several companies
mentioned that for non-uniform UE distribution, it can be addressed by gNB
implementation e.g. by adjusting SSB beamwidth, etc. Several companies also
mentioned that it is not clear how gNB can predict the distribution of UEs in
different beams, especially for Idle/Inactive UEs.
- Note 2: Most
sources that showed the NES gains (if any) for adaptation of PRACH in
spatial domain compared to A1-2/B1 observed that the gain would be due to
reduction in the number of overall ROs in time domain in their
evaluations. Most of these companies only accounted for ROs in time
domain.
- Note 3: The
evaluation results assumed the non-uniform distribution of UE is static
during the evaluation time period.
Conclusion
There is
no consensus in RAN1 on the support of PRACH adaptation in spatial domain.
R1-2405631 Summary#4 of AI
9.5.3 for R19 NES Moderator (Ericsson)
From
Friday session
Agreement
For
adaptation of SSB in time-domain, Option 1 is supported
- Option
1: Adaptation of SSB burst periodicity using one or more SSB burst
periodicity value(s)
- Note:
Using Option 2 to realize Option 1 is not precluded
- Option
2: Adaptation based on two SSB configurations [where up to two
configurations can be active]
- FFS:
details of the differences between the two SSB configurations, e.g. two
different periodicities
- FFS:
Details including applicable scenarios
- FFS:
Support of Cell DTX for connected mode UEs for SSB
Agreement
For
adaptation of PRACH in time-domain, the additional PRACH resources are
configured based on at least:
- a
PRACH configuration index
- FFS:
whether the PRACH configuration index is same and/or different from the
PRACH configuration index for the legacy PRACH resources
Study
further the following
- When
the PRACH configuration index for the additional PRACH resources is same
as the PRACH configuration index for the legacy resource,
- Additional
parameter(s) for determining the additional PRACH resources e.g.
- Scaled/adjusted
PRACH configuration period
- Additional
timing offset
- Adjusting
the parameters (e.g., (x, y) value and slot number) of the PRACH
configuration
- Muting/masking
ROs
- When
the PRACH configuration index for the additional PRACH resources is
different from the PRACH configuration index for the legacy resource
- Additional
mechanisms (if any) for determining the additional PRACH resources e.g.
- Muting/masking
ROs (e.g. for the case when the PRACH configuration index for the
additional PRACH resources contains legacy resources)
- Additional
parameters to facilitate condensed/cluster RACH resources in time-domain
(including whether needed)
Agreement
For
the adaptation mechanism for additional PRACH resources, study further the
following:
- Option
1: Higher layer signalling (with potential enhancements) based PRACH
resource adaptation
- Option
2: L1-based adaptation to indicate whether the additional PRACH resources
provided by semi-static signalling are available or not
- FFS:
details
- Strive
to re-use existing DCI format(s)
- Option
3: Adaptation of PRACH transmission according to predefined condition(s)
- Option
4-rev1: L1-based adaptation to indicate whether a
subset of the additional PRACH resources provided by semi-static
signalling are available or not
- FFS: whether
the subset of the additional PRACH resources is in RO level /
SSB-to-RO mapping cycle level/PRACH association period level/PRACH
association pattern period level for time-domain PRACH
adaptation
- Strive to re-use
existing DCI format(s)
- Option
5: Enhanced cell DRX
Final
summary in R1-2405743.
Please refer to RP-241650 for detailed scope of
the WI.
[118-R19-NES] – Ajit (Ericsson)
Email discussion on Rel-19 NES enhancement
-
To be used for sharing
updates on online/offline schedule, details on what is to be discussed in
online/offline sessions, tdoc number of the moderator summary for online
session, etc
R1-2405811 Discussion of on-demand SSB Scell operation FUTUREWEI
R1-2405856 On-demand SSB SCell operation for eNES Huawei, HiSilicon
R1-2405894 On-demand SSB SCell operation Tejas Networks Limited
R1-2405916 Discussion on on-demand SSB SCell operation Spreadtrum
Communications
R1-2405957 On-demand SSB SCell Operation Google
R1-2405993 Discussion on on-demand SSB SCell operation CMCC
R1-2406021 Design of on-demand SSB SCell operation Intel Corporation
R1-2406049 On-demand SSB SCell Operation Nokia, Nokia Shanghai Bell
R1-2406095 Discussion on on-demand SSB operation for SCell China
Telecom
R1-2406190 Discussions on on-demand SSB Scell operation vivo
R1-2406226 Discussion on the enhancement to support on demand SSB
SCell operation OPPO
R1-2406292 Discussion on on-demand SSB SCell operation Xiaomi
R1-2406376 Discussion on on-demand SSB SCell operation CATT
R1-2406409 Discussion on on-demand SSB for NES ZTE Corporation,
Sanechips
R1-2406477 On-demand SSB SCell operation Sony
R1-2406507 Discussion on on-demand SSB SCell operation InterDigital,
Inc.
R1-2406515 Discussion on on-demand SSB SCell operation Fujitsu
R1-2406608 On-demand SSB SCell operation LG Electronics
R1-2406658 On-demand SSB SCell operation Samsung
R1-2406689 On-demand SSB SCell operation Lenovo
R1-2406694 Discussion on on-demand SSB for SCell operation NEC
R1-2406704 Discussion on On-Demand SSB SCell operation Transsion
Holdings
R1-2406708 DCI based signaling for on-demand SSB ASUSTeK
R1-2406732 Discussion on On-demand SSB SCell operation ETRI
R1-2406758 On-demand SSB SCell operation MediaTek Inc.
R1-2406783 Discussion on on-demand SSB SCell operation Panasonic
R1-2406847 On-demand SSB SCell Operation Apple
R1-2406902 Discussion of On-demand SSB SCell operation Mavenir
R1-2406938 Discussion on on-demand SSB SCell operation NTT
DOCOMO, INC.
R1-2406971 Discussion on details of on-demand SSB operation on Scell Sharp
R1-2407037 On-demand SSB operation for Scell Qualcomm
Incorporated
R1-2407056 On-demand SSB SCell operation Ericsson
R1-2407080 Discussion on on-demand SSB Scell operation CEWiT
R1-2407330 Summary #1 of on-demand SSB for NES Moderator (LG
Electronics)
From Monday session
Agreement
- Update the
previous RAN1 agreement as follows.
- At least
support L1 measurement based on on-demand SSB
- For L1
measurement based on on-demand SSB, periodic, semi-persistent,
[and aperiodic]
L1 measurement reports based on existing CSI framework are supported.
- FFS on
potential enhancements of CSI report configuration and/or
triggering/activation mechanisms for L1 measurement based on on-demand
SSB
- The
support of LTM is a separate discussion point
R1-2407331 Summary #2 of on-demand SSB for NES Moderator (LG
Electronics)
From Tuesday session
Agreement
For a cell supporting on-demand SSB SCell
operation,
- Support
RRC based signaling to indicate on-demand SSB transmission on the cell at
least for the case where this
RRC also configures the SCell, activates the SCell, and provides on-demand
SSB configuration.
- FFS:
Whether to support RRC based signaling for other cases.
- Support
MAC CE based signaling to indicate on-demand SSB transmission on the cell
for Scenarios #2 and #2A.
Note:
Deactivation and adaptation of on-demand SSB transmission can be separately
discussed.
R1-2407332 Summary #3 of on-demand SSB for NES Moderator (LG
Electronics)
From Wednesday session
Agreement
For a cell supporting on-demand SSB SCell operation, at least for the
following parameter(s), multiple candidate values can be configured by RRC and
the applicable value can be indicated by MAC CE for on-demand SSB transmission
indication for the cell.
- Periodicity
of the on-demand SSB.
- FFS:
Any other relevant parameters.
Agreement
For a cell supporting on-demand SSB SCell
operation, at least the
following is supported.
- On-demand
SSB on the cell is not located on synchronization raster.
- On-demand
SSB on the cell is non-cell-defining SSB.
FFS:
Additional support of OD-SSB for CD-SSB located on sync-raster.
Agreement
Support L3
measurement based on on-demand SSB.
- Further work
on L3 measurement is up to RAN2/RAN4.
R1-2407437 DRAFT LS to RAN2 for on-demand SSB SCell operation Moderator
(LG Electronics)
Agreement
Draft LS to RAN2 for on-demand SSB SCell
operation is endorsed. Final LS is approved in R1-2407438.
R1-2407333 Summary #4 of on-demand SSB for NES Moderator (LG
Electronics)
From Friday session
Agreement
The
previous RAN1 agreement made in RAN1#117 is revised as
follows.
- For SSB burst(s)
indicated by on-demand SSB SCell operation via MAC CE, UE expects that
on-demand SSB burst(s) is transmitted from time instance A which is
determined as follows.
- Alt 3-1: Time
instance A is the beginning of the first slot
containing [candidate SSB index 0 or the first actually transmitted SSB
index] of on-demand SSB burst
[the slot boundary of] the first SSB
time domain position [of actually transmitted on-demand SSB burst] which
is at least T [slots or
symbols] after the [slot
or symbol] where UE receives a
signalling from gNB to indicate on-demand SSB transmission
- The SSB time
domain positions of on-demand SSB burst are configured by gNB.
FFS: Details of
the value of T (≥ 0) including possibility of T comprising of
multiple components- Note: The value of
T is not less than existing timeline required for UE’s MAC CE processing
for SCell activation
- (Working assumption): T is not less than
T_min=
+1 where slot n+m
is a
slot indicated for PUCCH transmission with HARQ-QCK information when the
UE receives MAC CE signaling to indicate on-demand SSB transmission
ending in slot n, and 
is as defined in
current specification.
- RAN4 to confirm
that T_min can be equal to +1
FFS: Whether the
value of T is predefined or indicated/configured by gNB- (Working
assumption)
T=T_min
FFS: Details of
“the [slot or symbol] where UE receives a signalling from gNB” or “the
[slot or symbol] where UE transmits HARQ-ACK corresponding to a
signalling from gNB to trigger on-demand SSB”
- Above applies at
least for the case where SCell with on demand SSB transmission and cell
with signalling transmission have the same numerology.
R1-2407549 Draft LS on timeline for On-demand SSB operation on SCell Apple
Friday decision: The draft LS is endorsed.
Final LS is approved in R1-2407565.
Final summary in R1-2407543.
R1-2405812 Discussion of on-demand SIB1 for idle/inactive mode UEs FUTUREWEI
R1-2405857 Discussion on on-demand SIB1 for eNES Huawei, HiSilicon
R1-2405893 On-demand SIB1 for idle/inactive mode UEs Tejas
Networks Limited
R1-2405917 Discussion on on-demand SIB1 for idle/inactive mode UEs Spreadtrum
Communications
R1-2405958 On-demand SIB1 for Idle/Inactive Mode UE Google
R1-2405994 Discussion on on-demand SIB1 for UEs in idle/inactive mode CMCC
R1-2406022 Study of on-demand SIB1 for idle/inactive mode UEs Intel
Corporation
R1-2406050 On-demand SIB1 for Idle/Inactive mode UEs Nokia,
Nokia Shanghai Bell
R1-2406096 Discussion on on-demand SIB1 for idle/inactive mode UEs China
Telecom
R1-2406191 Discussions on on-demand SIB1 for idle/inactive mode UEs vivo
R1-2406227 Discussion on the enhancement to support on demand SIB1 for
idle/inactive mode UE OPPO
R1-2406293 Discussion on on-demand SIB1 for idle/inactive mode UEs Xiaomi
R1-2406377 Discussion on on-demand SIB1 CATT
R1-2406410 Discussion on on-demand SIB1 for NES ZTE Corporation,
Sanechips
R1-2406478 On-demand SIB1 for idle/inactive mode UEs Sony
R1-2406508 Discussion on on-demand SIB1 for idle/inactive mode UEs InterDigital,
Inc.
R1-2406516 Discussion on on-demand SIB1 for idle/inactive mode UEs Fujitsu
R1-2406609 On-demand SIB1 for idle/inactive mode UEs LG
Electronics
R1-2406659 On-demand SIB1 for idle/inactive mode UEs Samsung
R1-2406690 On-demand SIB1 for idle/inactive mode UEs Lenovo
R1-2406695 Discussion on on-demand SIB1 for UEs in idle/inactive mode NEC
R1-2406705 Discussion on on-demand SIB1 transmission for idle/inactive
mode UEs Transsion Holdings
R1-2406709 Triggering of on-demand SIB1 ASUSTeK
R1-2406733 On-demand SIB1 for idle/inactive mode UEs for NES ETRI
R1-2406759 On-demand SIB1 for idle or inactive mode UEs MediaTek
Inc.
R1-2406784 Discussion on on-demand SIB1 for idle/inactive mode UEs Panasonic
R1-2406848 On On-demand SIB1 for IDLE/INACTIVE mode UEs Apple
R1-2406939 Discussion on on-demand SIB1 for idle/inactive mode UEs NTT
DOCOMO, INC.
R1-2406968 Discussion on on-demand SIB1 in idle/inactive mode CAICT
R1-2406972 Discussion on on-demand SIB1 transmission for idle UEs Sharp
R1-2407038 On-demand SIB1 procedure Qualcomm Incorporated
R1-2407057 Study of on-demand SIB1 for UEs in idle/inactive mode for
NES Ericsson
R1-2407081 Discussion on on-demand SIB1 CEWiT
R1-2407103 On-demand SIB1 for NES Fraunhofer IIS, Fraunhofer HHI,
Vodafone, Deutsche Telekom, CEWiT
R1-2407127 On-demand SIB1 for Idle/Inactive mode UEs III
R1-2407156 Discussion on on-demand SIB1 for idle/inactive mode UEs DENSO
CORPORATION
R1-2407213 FL summary 1 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Monday session
Agreement
For
further work on on-demand SIB1 in idle/inactive mode, as a baseline, it is
assumed that the transmit power control of UL WUS transmission based on PRACH
is applied in the same manner as the legacy PRACH transmission.
·
FFS: Potential optimization
of the power ramp-up procedure.
Agreement
For
further work on on-demand SIB1 in idle/inactive mode related to dedicated PRACH resource usage,
RAN1 to study the following options:
· Option 1 (shared RO): The dedicated WUS
resource shares the same PRACH resource pool with PRACH resource for other
usages.
·
Option 2 (separated RO):
The dedicated WUS resource uses an independent RACH resource pool with PRACH
resource for other usages.
Agreement
RAN1 not to support on-demand SIB1 request that is combined with
an initial access to perform RRC connection establishment/resume on the NES
cell.
Agreement
RAN1
assumes the UE is expected to receive the RAR responding to the preamble
transmission for Msg1-based on-demand SIB1 procedure, as the baseline.
Agreement
At
least for Case-2: For further study of type 0 PDCCH monitoring occasions for on
demand SIB1, on the starting time and duration of the
time window of type 0 PDCCH monitoring occasions, RAN1 to down select from the
following two options:
·
Option 1: starting time and duration are indicated in RAR of the UL-WUS transmission
·
Option 2: starting time and
duration are indicated in the UL WUS configuration
Agreement
At
least for Case-2: For further study of type 0 PDCCH monitoring occasions for on
demand SIB1, on reference time point to determine the
window starting time, RAN1 to down select from the following two options:
·
Option 1: The reference time point is defined based on the RAR
reception time of the UL-WUS transmission
o
FFS: Definition of RAR
reception time
·
Option 2: The reference
time point is defined based on the UL-WUS transmission time
·
Option 3: The reference
time point is defined based on the RAR window of the UL-WUS transmission
R1-2407214 FL summary 2 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Tuesday session
Agreement
For on-demand SIB1 in idle/inactive mode,
Case 3 (Option 2+B+Y) is feasible from RAN1 perspective for some scenarios.
Case 3 (Option 2+B+Y) is lower priority compared to Case 2 from RAN1
perspective.
- RAN1 is inconclusive on whether the
required specification support is justified by the observed NES gain for
Case 3
R1-2407215 FL summary 3 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Wednesday session
Conclusion
For on-demand SIB1 in idle/inactive mode,
RAN1 was not able to achieve consensus to support Case 1 (Option 1+A+X) in
Rel-19, while Case 1 is technically possible from RAN1’s perspective.
Agreement
RAN1 recommends specifying on-demand SIB1
only for Case 2 (Option 1+B+X) in Rel-19.
·
Note: RAN1 strive to
minimize impact to legacy UE.
·
Note: RAN1 specification
impact to support this feature should be minimized.
Agreement
For Case-2: For type 0 PDCCH monitoring
occasions for on demand SIB1, on how the search space zero configuration is
provided, RAN1 to down select from the following options:
- Option 1: searchSpaceZero for
on-demand SIB1 is provided from MIB on NES cell
- Option 2: searchSpaceZero for
on-demand SIB1 is provided from UL WUS configuration
- Option 3: searchSpaceZero for
on-demand SIB1 is provided from the RAR of UL WUS.
Combination of multiple options is not
precluded.
R1-2407216 FL summary 4 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
Presented in Friday session.
Final summary in R1-2407217.
R1-2405813 Discussion of the adaptation of common signal/channel
transmissions FUTUREWEI
R1-2405858 On common channel/signal adaptation for eNES Huawei,
HiSilicon
R1-2405892 Adaptation of common signal/channel transmissions Tejas
Networks Limited
R1-2405918 Discussion on adaptation of common signal/channel
transmissions Spreadtrum Communications
R1-2405959 Adaptation of Common Signals Google
R1-2405995 Discussion on adaptation of common signal/channel
transmissions CMCC
R1-2406023 Adaptation of common signal/channel transmissions for
Network Energy Saving Intel Corporation
R1-2406051 Adaptation of common signal/channel transmissions Nokia,
Nokia Shanghai Bell
R1-2406097 Discussion on common signal/channel adaptation China
Telecom
R1-2406192 Discussions on adaptation of common signal/channel
transmissions vivo
R1-2406228 Discussion on adaptation of common signal/channel
transmission OPPO
R1-2406294 Discussion on adaptation of common signal and channel
transmissions Xiaomi
R1-2406378 Discussion on adaptation of common signal/channel
transmissions CATT
R1-2406411 Discussion on common signal channel for NES ZTE
Corporation, Sanechips
R1-2406479 Adaptation of common signal/channel transmissions Sony
R1-2406509 Discussion on adaptation of common signal/channel
transmissions InterDigital, Inc.
R1-2406517 Discussion on adaptation of common signal / channel
transmissions Fujitsu
R1-2406582 Discussion on adaptation of common signal channel
transmissions HONOR
R1-2406610 Adaptation of common signal/channel transmissions LG
Electronics
R1-2406660 Adaptation of common signal/channel transmissions Samsung
R1-2406696 Discussion on adaptation of common signal/channel
transmissions for Cell DTX/DRX NEC
R1-2406706 Discussion on adaptive transmission of common signal or
common channel Transsion Holdings
R1-2406712 Discussion on adaptation of common signal/channel
transmission Panasonic
R1-2406734 Adaptation of common signal/channel transmissions for NES ETRI
R1-2406760 Adaptation of common signal/channel transmissions MediaTek
Inc.
R1-2406807 Adaptation of common signals and channels Lenovo
R1-2406849 On adaptation of common signal/channel for NES enhancements Apple
R1-2406940 Discussion on adaptation of common signal/channel
transmissions NTT DOCOMO, INC.
R1-2406973 Discussion on adaptation of common signal/channel
transmissions Sharp
R1-2407039 Adaptation of common channel transmissions Qualcomm
Incorporated
R1-2407058 Adaptation of common signal/channel transmissions for NES Ericsson
R1-2407069 Discussion on adaptation of common signal/channel
transmissions ITRI
R1-2407082 Discussion on adaptation of common signal and channel
transmissions CEWiT
R1-2407100 Adaptation of Common Signals and Channels for NES Fraunhofer
IIS, Fraunhofer HHI
R1-2407157 Discussion on adaptation of common signal/channel
transmissions DENSO CORPORATION
R1-2407277 Summary#1 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Monday session
Agreement
For
adaptation of PRACH in time-domain, select at least one from the following
alternatives for configuration of the additional PRACH resources
- Alt
1: The PRACH configuration index for the additional PRACH resources is
same as the PRACH configuration index for the legacy resources and
- Discuss
further additional mechanism(s) for determining the additional PRACH
resources, e.g.
- Opt
1-1: Scaled/adjusted PRACH configuration period
- Opt
1-2: Adjusting the parameters (e.g., (x, y) value and slot number) of
the PRACH configuration
- Opt
1-3: Muting/masking ROs
- Opt
1-4: additional timing offset(s)
- Alt
2: The PRACH configuration index for the additional PRACH resources is
different from the PRACH configuration index for the legacy resources,
- Discuss
further additional mechanism(s) for determining the additional PRACH
resources, e.g.
- Opt
2-1: Muting/masking ROs (e.g. for the case when the PRACH configuration
index for the additional PRACH resources contains legacy resources)
- Opt
2-2: Additional timing offset(s)
- FFS:
Additional parameters to facilitate condensed/cluster RACH resources in
time-domain (including whether needed)
- FFS:
Additional frequency domain parameter(s) (e.g., freq. starting offset)
Agreement
Extend
the RAN1#117 agreement on SSB-RO mapping rule for additional PRACH resources to
Case 1
- Case
1: no time-domain overlap between the additional PRACH resources for
NES-capable UEs and the PRACH resources for legacy UEs
RAN1#117
Agreement
At least for the
case where legacy ROs and additional ROs overlap in neither time nor frequency
domain, for adaptation of PRACH in time-domain, the SSB-RO mapping rule for
additional PRACH resources follows the legacy SSB-RO mapping rule.
·
Mapping SS/PBCH block indexes to valid
additional PRACH occasions provided by semi-static signalling follows the
legacy mapping order for preamble/time resource/frequency/PRACH slot indexes.
o Note:
This mapping is not impacted by time domain PRACH adaptation
·
Validation rules for the additional PRACH
resources follow the legacy validation rules for PRACH resources configured for
legacy UEs.
Agreement
For
SSB-RO mapping rule for additional PRACH resources for Case 2.
- Extend
the RAN1#117 and RAN1#118 agreements on SSB-RO mapping.
Agreement
For
the adaptation mechanism for additional PRACH resources (for CONNECTED mode UE
and IDLE/INACTIVE mode UE),
·
At least DCI based
adaptation is supported. No introduction of new DCI format.
R1-2407278 Summary#2 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Tuesday session
Agreement
For
adaptation mechanism(s) of SSB in time-domain,
- For Rel-19 NES-capable UE’s
PCell (Connected mode), adaptation of CD-SSB on sync raster is not
supported
- FFS: Adaptation for SSB that
is not CD-SSB is supported (A2)
- FFS: Adaptation for SSB not
on sync raster is supported (A3)
- For Rel-19 NES-capable UE’s
SCell
- Adaptation of SSB configured
for the SCell is supported for the following cases
- FFS: Adaptation for CD-SSB
(B1) including UE impact compared to legacy operation where the SSB is
configured with periodicity>20msec for SCell
- Adaptation for SSB that is
not CD-SSB on sync raster (B2’)
- Adaptation for SSB that is
not CD-SSB not on sync raster (B3’)
Agreement
For
DCI-based adaptation for additional PRACH resources,
- Select from the
following DCI format(s) to carry the adaptation indication.
- DCI format 1_0
- DCI format 2_7
- DCI format 2_9
- FFS: existing
(P-RNTI, SI-RNTI, CellDTRX-RNTI, PEI-RNTI, C-RNTI) or new RNTI used for
detecting the DCI format.
R1-2407408 Summary#3 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Wednesday session
Agreement
For Cell DTX extension to SSBs not on
sync-raster for connected mode UEs, select from following options
- Option
1: One SSB burst periodicity is configured for the UE and UEs assumes SSB
transmissions are not present during Cell DTX non-active period
- Option
2: UE assumes SSB transmission with different periodicities during Cell
DTX non-active period and during Cell DTX active period
- Option
3: Cell DTX does not impact UE assumption on SSB transmissions (i.e.
legacy behavior) – no spec impact
R1-2407409 Summary#4 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Friday session
Agreement
For
DCI-based adaptation for additional PRACH resources, select only from the
following alternatives
- Alt
1: (PRACH resource configuration level) DCI-based adaptation to indicate
whether the additional PRACH resources provided by semi-static signalling
are available or not
- Alt
2: (subset of PRACH resource level) DCI-based adaptation to indicate
whether a subset of the additional PRACH resources provided by
semi-static signalling are available or not
- FFS: whether
the subset of the additional PRACH resources is in
- Alt
2-1: RO level per SSB
- Alt
2-2: SSB-to-RO mapping cycle level
- Alt
2-3: PRACH association period level
- Alt
2-4: PRACH association pattern period level
- Alt
2-5: SFN level
- Alt
3: DCI-based
Enhanced/new Cell DRX to indicate whether the enhanced/new Cell DRX is
activated or deactivated.
- If
activated, the additional configured PRACH provided by semi-static
signalling within non-active period are not available.
- FFS:
whether Alt 1 and/or Alt 2 can be applied to the active period
- FFS:
details
Final summary in R1-2407552.
Please refer to RP-242354
for detailed scope of the WI.
[118bis-R19-NES] – Ajit (Ericsson)
Email discussion on Rel-19 NES enhancement
-
To be used for sharing updates on
online/offline schedule, details on what is to be discussed in online/offline
sessions, tdoc number of the moderator summary for online session, etc
R1-2408816 Updated
workplan for Rel-19 network energy savings WI Rapporteurs (Ericsson,
Apple)
R1-2407619 Discussion of on-demand SSB Scell operation FUTUREWEI
R1-2407685 On-demand SSB SCell operation for eNES Huawei, HiSilicon
R1-2407711 Discussion on on-demand SSB SCell operation Spreadtrum
Communications
R1-2407738 Discussion on on-demand SSB operation for SCell China
Telecom
R1-2407757 On demand SSB Tejas Network Limited
R1-2407792 On-demand SSB SCell Operation Nokia, Nokia Shanghai Bell
R1-2407866 Discussions on on-demand SSB Scell operation vivo
R1-2407910 Discussion on on-demand SSB SCell operation CMCC
R1-2407974 Discussion on on-demand SSB SCell operation Xiaomi
R1-2407995 On-demand SSB SCell Operation Google
R1-2408052 Discussion on on-demand SSB SCell operation CATT
R1-2408071 Discussion on on-demand SSB for NES ZTE Corporation,
Sanechips
R1-2408121 Discussion on On-Demand SSB SCell operation Transsion
Holdings
R1-2408132 Discussion on the enhancement to support on demand SSB
SCell operation OPPO
R1-2408248 Discussion of On-demand SSB SCell operation Mavenir
R1-2408311 Discussion on on-demand SSB SCell operation InterDigital,
Inc.
R1-2408326 On-demand SSB SCell operation Lenovo
R1-2408342 Discussion on on-demand SSB SCell operation Panasonic
R1-2408376 Discussion on on-demand SSB for SCell operation NEC
R1-2408413 On-demand SSB SCell operation Sony
R1-2408473 On-demand SSB SCell Operation Apple
R1-2408503 Discussion on on-demand SSB SCell operation Fujitsu
R1-2408572 Discussion on On-demand SSB SCell operation ETRI
R1-2408651 On-demand SSB SCell operation Samsung
R1-2408676 On-demand SSB SCell operation LG Electronics
R1-2408706 On-demand SSB SCell operation MediaTek Inc.
R1-2408791 Discussion on on-demand SSB SCell operation NTT
DOCOMO, INC.
R1-2408817 On-demand SSB SCell operation Ericsson
R1-2408830 Discussion on on-demand SSB SCell operation ITRI
R1-2408855 On-demand SSB operation for Scell Qualcomm
Incorporated
R1-2409009 Discussion on details of on-demand SSB operation on SCell SHARP (rev
of R1-2408878)
R1-2408909 DCI based signaling for on-demand SSB ASUSTeK
R1-2408934 Discussion on on-demand SSB Scell operation CEWiT
R1-2409107 Summary #1 of on-demand
SSB for NES Moderator (LG Electronics)
From Tuesday session
Agreement
For a cell
supporting on-demand SSB SCell operation, deactivation
of on-demand SSB transmission is supported. In order to deactivate on-demand
SSB transmission from a UE perspective, support at least one of the following
options.
- Option 1: Explicit indication of
deactivation for on-demand SSB via MAC-CE for on-demand SSB transmission
indication
- Option 1A: Explicit indication of
deactivation for on-demand SSB via RRC for on-demand SSB transmission
indication
- Option
2: Configuration/indication of the number N of
on-demand SSB bursts to be transmitted after on-demand SSB is indicated
- Option 3: Configuration/indication of
the duration of on-demand SSB transmission window
- Option 4: On-demand SSB transmission,
if any, is deactivated when UE receives SCell deactivation MAC-CE for the
activated SCell
- Option 4A: On-demand SSB transmission,
if any, is deactivated when the timer for SCell deactivation is expired
- Option 5: On-demand SSB transmission,
if any, is deactivated when SCell activation is completed
- Option 6: Explicit indication of
deactivation for on-demand SSB via [group-common] DCI
- FFS: Each option is applicable to which Cases or
Scenarios
- FFS: Details related to each of the
above options
R1-2409108 Summary #2 of on-demand
SSB for NES Moderator (LG Electronics)
From Wednesday session
Agreement
- For a cell supporting on-demand SSB
SCell operation, support to provide at least the following
parameters for on-demand SSB configuration by RRC at least for Case #1.
- Sub-carrier spacing of the on-demand SSB
- FFS if this can be absent
- Physical
Cell ID of the on-demand SSB
- FFS:
Time domain location of on-demand SSB burst such as SFN offset and half
frame index
- Downlink transmit power of on-demand SSB
- FFS: The number N of
on-demand SSB bursts to be transmitted after on-demand SSB is indicated
- FFS whether the above parameters are configured
by reusing legacy RRC parameters or new RRC parameters
Agreement
- For a cell supporting on-demand SSB
SCell operation and for Case #2 (i.e., Always-on SSB
is periodically transmitted on the cell), consider
only one or both of the following options for UE to perform L1 measurement
based on on-demand SSB.
- Option 1: A CSI report configuration is
associated with both of on-demand SSB and always-on SSB
- Option
2: A CSI report configuration is associated with one of always-on SSB and
on-demand SSB
- FFS: Whether OD-SSB and always on SSB have same
beam or not
Conclusion
No
consensus on the support of on-demand SSB SCell operation triggered by UE.
R1-2409109 Summary #3 of on-demand
SSB for NES Moderator (LG Electronics)
From Thursday session
Agreement
The
previous RAN1 agreement is partly confirmed and further
revised as follows.
- For SSB burst(s)
indicated by on-demand SSB SCell operation via a MAC
CE, UE expects that on-demand SSB
burst(s) is transmitted from time instance A which is
determined as follows.
- Alt 3-1: Time
instance A is the beginning of the first slot containing [candidate SSB
index 0 or the first actually transmitted SSB index]
ofwithin the first “possible” on-demand SSB burst which
is at least T slots after the slot
where UE receives a signalling from gNB to indicate on-demand SSB
transmission
- The SSB time
domain positions of on-demand SSB burst are configured by gNB.
- The location(s)
(e.g., SFN offset, half frame index) in the time domain of “possible” on-demand
SSB burst and SSB position within the burst should be configured by the
gNB
- Note: The value of
T is not less than existing timeline required for UE’s MAC CE processing
for SCell activation
- (Working assumption): T is not less than
T_min=
+1 where slot n+m
is a
slot indicated for PUCCH transmission with HARQ-QCK information when the
UE receives MAC CE signaling to indicate on-demand SSB transmission
ending in slot n, and 
is as defined in current
specification.
- RAN4 to confirm
that T_min can be equal to +1
- (Working
assumption)
T=T_min
- Above applies at
least for the case where SCell with on demand SSB transmission and cell
with signalling transmission have the same numerology.
Agreement
For a cell supporting on-demand SSB SCell
operation and for Case #2
(i.e., Always-on SSB is
periodically transmitted on the cell), study at least the following Mux-Cases.
- Mux-Case
#1: No time-domain overlap between always-on SSB and on-demand SSB.
- Mux-Case
#2: Always-on SSB and on-demand SSB overlap at least in time or frequency
domain.
R1-2409110 Summary #4 of on-demand
SSB for NES Moderator (LG Electronics)
Presented in Friday session.
Final summary in R1-2409289.
R1-2407620 Discussion of on-demand SIB1 for idle/inactive mode UEs FUTUREWEI
R1-2407686 Discussion on on-demand SIB1 for eNES Huawei, HiSilicon
R1-2407712 Discussion on on-demand SIB1 for idle/inactive mode UEs Spreadtrum
Communications
R1-2407739 Discussion on on-demand SIB1 for idle/inactive mode UEs China
Telecom
R1-2407758 On demand SIB1 Tejas Network Limited
R1-2407793 On-demand SIB1 for Idle/Inactive mode UEs Nokia,
Nokia Shanghai Bell
R1-2407867 Discussions on on-demand SIB1 for idle/inactive mode UEs vivo
R1-2407911 Discussion on on-demand SIB1 for UEs in idle/inactive mode CMCC
R1-2407975 Discussion on on-demand SIB1 for idle/inactive mode UEs Xiaomi
R1-2407996 On-demand SIB1 for Idle/Inactive Mode UE Google
R1-2408053 Discussion on on-demand SIB1 CATT
R1-2408072 Discussion on on-demand SIB1 for NES ZTE Corporation,
Sanechips
R1-2408122 Discussion on on-demand SIB1 transmission for idle/inactive
mode UEs Transsion Holdings
R1-2408133 Discussion on the enhancement to support on demand SIB1 for
idle/inactive mode UE OPPO
R1-2408312 Discussion on on-demand SIB1 for idle/inactive mode UEs InterDigital,
Inc.
R1-2408321 Discussion on on-demand SIB1 for idle/inactive mode UEs KT
Corp.
R1-2408327 On-demand SIB1 for idle/inactive mode UEs Lenovo
R1-2408343 Discussion on on-demand SIB1 for idle/inactive mode UEs Panasonic
R1-2408377 Discussion on on-demand SIB1 for UEs in idle/inactive mode NEC
R1-2408414 On-demand SIB1 for idle/inactive mode UEs Sony
R1-2408474 On On-demand SIB1 for IDLE/INACTIVE mode UEs Apple
R1-2408502 Discussion on on-demand SIB1 transmission for network
energy savings Fujitsu
R1-2408573 On-demand SIB1 for idle/inactive mode UEs ETRI
R1-2408582 On-demand SIB1 for Idle/Inactive mode UEs III
R1-2408591 Views on On-demand SIB1 operation for idle/inactive UEs Vodafone,
Deutsche Telekom
R1-2408606 Discussion on on-demand SIB1 transmission for idle UEs Sharp
R1-2408652 On-demand SIB1 for idle/inactive mode UEs Samsung
R1-2408677 On-demand SIB1 for idle/inactive mode UEs LG
Electronics
R1-2408707 On-demand SIB1 for idle or inactive mode UEs MediaTek
Inc.
R1-2408792 Discussion on on-demand SIB1 for idle/inactive mode UEs NTT
DOCOMO, INC.
R1-2408808 Discussion on on-demand SIB1 in idle/inactive mode CAICT
R1-2408818 On-demand SIB1 for UEs in idle/inactive mode for NES Ericsson
R1-2408856 On-demand SIB1 procedure Qualcomm Incorporated
R1-2408882 Discussion on on-demand SIB1 for idle/inactive mode UEs DENSO
CORPORATION
R1-2408910 Triggering of on-demand SIB1 ASUSTeK
R1-2408935 Discussion on on-demand SIB1 CEWiT
R1-2408951 On-demand SIB1 for NES Fraunhofer IIS, Fraunhofer HHI
R1-2409012 FL summary 1 for
on-demand SIB1 in idle/inactive mode Moderator (MediaTek)
From Tuesday session
Conclusion
No further optimization in RAN1 on power
control and power ramp-up procedure for UL WUS in R19.
Agreement
For the
purpose of “to which cell does the configuration applies”, at least the
following parameters are included in the UL-WUS configuration.
|
Purpose
|
Parameters
|
|
To
which cell does the configuration applies
|
NES-CellId
|
PhysCellId
|
|
ARFCN-ValueNR
|
Note:
ARFCN-ValueNR is used to indicate the absolute radio
frequency channel number (ARFCN) for SSB of NES cell.
Agreement
For the
purpose of “WUS transmission”, at least the following parameters are included
in the UL-WUS configuration:
·
rsrp-ThresholdSSB
·
prach-RootSequenceIndex
·
msg1-SubcarrierSpacing
·
restrictedSetConfig
Note: In
legacy spec, the parameters above are under the IE RACH-ConfigCommon
Agreement
For the
purpose of “WUS transmission”, at least the following parameters to indicate “frequency information for UL-WUS transmission” are included in the UL-WUS
configuration.
|
Purpose
|
Parameters
|
|
WUS
transmission
|
frequencyInfoUL
|
frequencyBandList
|
|
absoluteFrequencyPointA
|
|
offsetToCarrier
|
|
p-Max
|
|
frequencyShift7p5khz (working
assumption)ULSubCarrierSpacing
|
Agreement
For the
purpose of “WUS transmission”, at least the following parameters are included
in the UL-WUS configuration.
|
Purpose
|
Parameters
|
|
WUS
transmission
|
SIB1-RequestConfig
|
ss-PBCH-BlockPower
|
|
SSB-positionInBurst
|
|
tdd-UL-DL-ConfigurationCommon
|
|
rach-OccasionsSIB1
|
Prach-ConfigurationIndex
|
|
msg1-FDM
|
|
msg1-FrequencyStart
|
|
zeroCorrelationZoneConfig
|
|
preambleReceivedTargetPower
|
|
preambleTransMax
|
|
powerRampingStep
|
|
ra-ResponseWindow
|
|
ssb-perRACH-Occasion
|
|
sib1-RequestPeriod
|
|
sib1-RequestResources
|
ra-PreambleStartIndex
|
|
ra-AssociationPeriodIndex
|
|
ra-ssb-OccasionMaskIndex
|
Note:
·
In legacy spec,
ss-PBCH-BlockPower/SSB-positionInBurst/tdd-UL-DL-ConfigurationCommon are under
the IE ServingCellConfigCommon/ServingCellConfigCommonSIB
·
Msg1-FrequencyStart is with respect to the
first RB of the UE carrier determined by offsetToCarrier and
absoluteFrequencyPointA
R1-2409013 FL summary 2 for
on-demand SIB1 in idle/inactive mode Moderator (MediaTek)
From Thursday session
Agreement
For further work of on-demand SIB1 in
idle/inactive mode, it is assumed that:
·
SSB transmitted in the NES
cell supporting OD-SIB1 is with K_SSB > 23 for FR1 and K_SSB >11 for FR2
if it is transmitted on sync raster.
·
UE determines a cell
supporting OD-SIB1 based at least on UL WUS configuration from Cell A.
Agreement
For type 0 PDCCH monitoring occasions of on
demand SIB1, searchSpaceZero and controlResourceSetZero for on-demand SIB1 are
provided from UL WUS configuration if SSB on NES cell is on sync raster and
K_SSB is not equal to 30 in FR1 or 14 in FR2.
Agreement
For The repetition periodicity of SIB1
within the time window of on-demand SIB1,:
·
Up to NW implementation (no
change to existing specification)
Agreement
RAN1 to discuss the contents of RAR in
response to UL WUS using the
legacy RAR for OSI as a starting point.
R1-2409014 FL summary 3 for
on-demand SIB1 in idle/inactive mode Moderator (MediaTek)
From Friday session
Agreement
Search space for RAR in response to UL WUS
on a NES Cell can be provided by the UL WUS configuration. If not, follow the
search space zero for the NES Cell.
Agreement
It is up to gNB to configure whether RACH
occasions for UL WUS are shared or separated from the RACH occasions for other
usages.
Final summary in R1-2409016.
R1-2407621 Discussion of the adaptation of common signal/channel
transmissions FUTUREWEI
R1-2407687 On common channel/signal adaptation for eNES Huawei,
HiSilicon
R1-2407713 Discussion on adaptation of common signal/channel
transmissions Spreadtrum Communications
R1-2407740 Discussion on common signal/channel adaptation China
Telecom
R1-2407759 Adaptation of common signals/channels Tejas Network
Limited
R1-2407794 Adaptation of common signal/channel transmissions Nokia,
Nokia Shanghai Bell
R1-2407868 Discussions on adaptation of common signal/channel
transmissions vivo
R1-2407912 Discussion on adaptation of common signal/channel
transmissions CMCC
R1-2407976 Discussion on adaptation of common signal and channel
transmissions Xiaomi
R1-2407997 Adaptation of Common Signals Google
R1-2408054 Discussion on adaptation of common signal/channel
transmissions CATT
R1-2408073 Discussion on common signal channel for NES ZTE
Corporation, Sanechips
R1-2408123 Discussion on adaptive transmission of common signal or
common channel Transsion Holdings
R1-2408134 Discussion on adaptation of common signal/channel
transmission OPPO
R1-2408235 Discussion on adaptation of common signal channel
transmissions HONOR
R1-2408313 Discussion on adaptation of common signal/channel
transmissions InterDigital, Inc.
R1-2408352 Discussion on adaptation of common signal/channel
transmission Panasonic
R1-2408367 Adaptation of common signals and channels Lenovo
R1-2408378 Discussion on adaptation of common signal/channel
transmissions NEC
R1-2408415 Adaptation of common signal/channel transmissions Sony
R1-2408475 On adaptation of common signal/channel for NES
enhancements+B19 Apple
R1-2408501 Discussion on adaptation of common signal / channel
transmissions Fujitsu
R1-2408574 Adaptation of common signal/channel transmissions ETRI
R1-2408607 Discussion on adaptation of common signal/channel
transmissions Sharp
R1-2408653 Adaptation of common signal/channel transmissions Samsung
R1-2408678 Adaptation of common signal/channel transmissions LG
Electronics
R1-2408708 Adaptation of common signal/channel transmissions MediaTek
Inc.
R1-2408793 Discussion on adaptation of common signal/channel
transmissions NTT DOCOMO, INC.
R1-2408819 Adaptation of common signal/channel transmissions for NES Ericsson
R1-2408857 Adaptation of common channel transmissions Qualcomm
Incorporated
R1-2408936 Discussion on adaptation of common signal and channel
transmissions CEWiT
R1-2408950 Adaptation of Common Signals and Channels for NES Fraunhofer
IIS, Fraunhofer HHI
R1-2409150 Summary#1 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Tuesday session
Agreement
For
adaptation of PRACH in time-domain, the same PRACH preamble format is used for the additional RACH
resources and legacy PRACH resources.
Agreement
For
adaptation of PRACH in time-domain, support both of the following
- Alt 1:
The PRACH configuration index for the additional PRACH resources is same
as the PRACH configuration index for the legacy resources
- Alt 2:
The PRACH configuration index for the additional PRACH resources is
different from the PRACH configuration index for the legacy resources
- FFS:
Additional details
Possible
Agreement
For
DCI-based adaptation for additional PRACH resources the following is supported
-
Alt1A:
At least DCI format 1_0 can carry the adaptation indication for UEs in
idle/inactive and connected mode.
o
P-
RNTI is used
-
Alt1B:
At least DCI format 1_0 can carry the adaptation indication for UEs in
idle/inactive and connected mode.
o
New
RNTI is used
-
Alt2:
o
At
least DCI format 2_7 can carry the adaptation indication for UEs in
idle/inactive mode.
o
At
least DCI format 2_9 can carry the adaptation indication for UEs in connected
mode.
-
Alt3
o
Alt1
+ first sub-bullet of Alt2
R1-2409151 Summary#2 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Wednesday session
Working Assumption
For
DCI-based adaptation for additional PRACH resources,
- Alt1A2:
At least DCI format 1_0 can carry the adaptation indication for UEs in
idle/inactive and connected mode.
Agreement
For
adaptation of PRACH in time-domain, the frequency domain resources for the
additional PRACH resources and legacy PRACH resources can be same or different
- FFS:
applicable case(s) (i.e. case(s) from the RAN1#117 agreement).
- Discuss
further following options for signaling
- Option
1: at least the following parameter(s) can be configured separately for
the additional PRACH resources.
- msg1-FrequencyStart
at least for 4-step RACH
- FFS:
other applicable legacy frequency domain parameter(s)
- Option
2: Offset
to legacy frequency domain parameter(s) are configured for the additional
PRACH resources
- Note:
Offset to legacy frequency domain parameter(s) is a new parameter
- FFS:
applicable legacy frequency domain parameter(s)
R1-2409278 Summary#3 of AI
9.5.3 for R19 NES Moderator (Ericsson)
From
Friday session
Conclusion
There is no consensus on
the support of adaptation of SSB for idle mode UEs in Rel-19.
Agreement
For Cell DTX
extension to SSBs not on sync-raster for connected mode UEs, select Option 3,
i.e. Cell
DTX does not impact UE assumption on SSB transmissions (i.e. legacy behavior).
·
No spec impact
Agreement
For
adaptation of PRACH in time-domain, for determining the additional PRACH
resources in time-domain,
- For Alt
1 (same PRACH configuration index for additional and legacy PRACH
resources), select one or more of the following additional mechanism(s),
- Opt
1-2a: up to N1 additional value(s) of (x, y)
- Opt
1-2b: up to N2 additional value(s) of y
- Opt
1-3: Muting/masking ROs
- Opt
1-4:
- up to
N4_1 additional timing offset(s) at frame-level
- up to
N4_2 additional timing offset(s) at slot-level
- FFS:
values of N4_1(>=1) and N4_2(>=1)
- Opt
1-5: No additional mechanism is selected.
- Note: x
and y refer to the parameters from the random-access configuration tables
(from 38.211)
- For Alt
2 (different PRACH configuration index for additional and legacy PRACH
resources), select one or more of the following additional mechanism(s),
- Opt
1-2a: up to N1 additional value(s) of (x, y)
- Opt
1-2b: up to N2 additional value(s) of y
- Opt
1-3: Muting/masking ROs
- Opt
1-4:
- up to
N4_1 additional timing offset(s) at frame-level
- up to
N4_2 additional timing offset(s) at slot-level
- FFS:
values of N4_1(>=1) and N4_2(>=1)
- Opt
1-5: No additional mechanism is selected.
- Note: x
and y refer to the parameters from the random-access configuration tables
(from 38.211)
Final
summary in R1-2409279.
Please refer to RP-242354 for detailed scope of
the WI.
[119-R19-NES] – Ajit (Ericsson)
Email discussion on Rel-19 NES enhancement
-
To be used for sharing
updates on online/offline schedule, details on what is to be discussed in
online/offline sessions, tdoc number of the moderator summary for online
session, etc
From Friday session
R1-2410886 Draft reply LS on SSB relation in On-demand SSB and SSB
adaptation on Scell Moderator (Ericsson)
Decision:
The draft LS is endorsed. Final LS is approved in R1-2410917.
R1-2409413 On-demand SSB SCell operation for eNES Huawei, HiSilicon
R1-2409448 Discussion on on-demand SSB SCell operation Quectel
R1-2409517 Discussion on on-demand SSB SCell operation CMCC
R1-2409544 Discussion on on-demand SSB SCell operation Panasonic
R1-2409556 Discussion on on-demand SSB for NES ZTE Corporation,
Sanechips
R1-2409602 On-demand SSB SCell operation Samsung
R1-2409641 Discussion on on-demand SSB SCell operation Spreadtrum,
UNISOC
R1-2409686 Discussions on on-demand SSB Scell operation vivo
R1-2409712 On-demand SSB SCell Operation Nokia, Nokia Shanghai Bell
R1-2409735 Discussion on on-demand SSB SCell operation Intel
Corporation
R1-2409754 On demand SSB Tejas Networks Limited
R1-2409772 Discussion on on-demand SSB SCell operation InterDigital,
Inc.
R1-2409808 On-demand SSB SCell Operation Apple
R1-2409901 Discussion on on-demand SSB SCell operation Xiaomi
R1-2409946 Discussion on on-demand SSB SCell operation CATT
R1-2409965 Discussion on On-Demand SSB SCell operation Transsion
Holdings
R1-2410004 Discussion on on-demand SSB operation for SCell China
Telecom
R1-2410032 Discussion of on-demand SSB Scell operation FUTUREWEI
R1-2410062 Discussion on on-demand SSB SCell operation Fujitsu
R1-2410074 Discussion on the enhancement to support on-demand SSB
SCell operation OPPO
R1-2410156 On-demand SSB SCell Operation Google
R1-2410209 Discussion on on-demand SSB for SCell operation NEC
R1-2410228 On-demand SSB SCell operation Sony
R1-2410252 On-demand SSB SCell operation Lenovo
R1-2410271 Discussion on On-demand SSB SCell operation ETRI
R1-2410291 On-demand SSB SCell operation LG Electronics
R1-2410394 Discussion on on-demand SSB SCell operation NTT
DOCOMO, INC.
R1-2410430 Discussion on on-demand SSB SCell operation ITRI
R1-2410441 On-demand SSB SCell operation Ericsson
R1-2410483 On-demand SSB operation for Scell Qualcomm
Incorporated
R1-2410505 Discussion on details of on-demand SSB operation on SCell Sharp
R1-2410521 On-demand SSB SCell operation MediaTek Inc.
R1-2410550 DCI based signaling for on-demand SSB ASUSTeK
R1-2410563 Discussion of On-demand SSB SCell operation Mavenir
R1-2410581 Discussion on on-demand SSB Scell operation CEWiT
From AI 5
R1-2409350 LS on SSB relation in On-demand SSB and SSB adaptation on
Scell RAN4, Ericsson
Decision: Response
needed – Ajit (Ericsson).
R1-2410779 Summary #1 of on-demand SSB for NES Moderator (LG
Electronics)
From Tuesday session
Agreement
Response to Q1 (What is the relation in
terms of periodicity between always-on SSB and OD-SSB?)
of Obj.1:
- The periodicity of on-demand SSB is one of 5 ms, 10 ms, 20 ms,
40 ms, 80 ms, or 160 ms. RAN1 is discussing whether to introduce other
periodicity value(s) for on-demand SSB.
- The periodicity of on-demand SSB can be configured separately
from the periodicity of always-on SSB.
- RAN1 is discussing what is the relation between periodicity of
always-on SSB and periodicity of on-demand SSB and it has been identified
that the main use case is that the periodicity of on-demand SSB is equal
to or smaller than that of always-on SSB.
Further update to be made based on RAN1#119 progress.
Agreement
Response to Q3 (What is the relation in terms of frequency location between the
always-on SSB and OD-SSB?) of Obj.1:
- The frequency location of on-demand SSB is the same as the frequency location of always-on SSB at least for the case where always-on SSB is not CD-SSB. RAN1
is discussing the frequency location of OD-SSB for the case where
always-on SSB is CD-SSB.
R1-2410780 Summary #2 of on-demand SSB for NES Moderator (LG
Electronics)
From Wednesday session
Agreement
Response to Q4 (What is the spatial relation between the always-on SSB and OD-SSB?)
of Obj.1:
- SS/PBCH blocks with
the same SSB indexes for always-on SSB and on-demand SSB are quasi co-located with respect to
Doppler spread, Doppler shift, average gain, average delay, delay spread,
and when applicable, spatial RX parameters.
- Applies at least for the case when the centre frequency
locations of always-on SSB and OD-SSB is same
- When a signal/channel is configured to be QCLed with a SSB
index, the signal/channel is QCLed with the same SSB index of always-on SSB and on-demand SSB (if transmitted) with the same QCL
parameters according to existing specifications
- Applies at least for the case when the
centre frequency locations of always-on SSB and OD-SSB is same
- At least the case where SSB indices within on-demand SSB burst
are identical to SSB indices within always-on SSB burst is supported. RAN1
is discussing whether to support the case where SSB indices within
on-demand SSB burst can be subset of SSB indices within always-on SSB
burst.
R1-2410781 Summary #3 of on-demand SSB for NES Moderator (LG
Electronics)
From Thursday session
Agreement
- For a cell supporting on-demand SSB SCell
operation, support to
configure time
domain location of on-demand SSB per on-demand SSB periodicity by RRC for both Case #1 and Case #2.
- For
Case #1 (i.e., No
always-on SSB on the cell),
- Based on two
parameters, where one is to indicate SFN offset from a reference point
and the other is to indicate half frame index
- The
reference point is SFN which satisfies (SFN index *10) modulo (OD-SSB
periodicity) = 0
- If
SFN offset parameter is NOT configured, UE assumes SFN offset set to 0.
- If
half frame index parameter is NOT configured, UE assumes half frame
index set to 0.
- The
value range of SFN offset is 0 to 15 unless longer periodicity for
on-demand SSB than 160 ms is introduced.
- The
value range of half frame index is 0 or 1.
- For Case #2
(i.e., Always-on SSB is
periodically transmitted on the cell), down-select one of the following alternatives.
- Alt A: Same
as for Case #1
- Alt B: Based
on a single parameter which is to indicate the time offset between
always-on SSB and on-demand SSB (e.g., similar to ssb-TimeOffset)
Agreement
New periodicity value for on-demand SSB
other than the legacy values (i.e., 5 ms, 10 ms, 20 ms, 40 ms, 80 ms, or 160
ms) is NOT introduced in Rel-19.
Agreement
Down-select at least one of the following alternatives.
- Alt 1: If always-on SSB is CD-SSB on a
synchronization raster, the frequency location of
on-demand SSB is different
from the frequency location of always-on SSB.
- Alt 2: If always-on SSB is CD-SSB on a
synchronization raster, the frequency location of
on-demand SSB is the same as the frequency location of always-on SSB
- Alt 3: Do not support the case where always-on SSB is CD-SSB on
a synchronization raster.
Down-select at least one of the following alternatives.
- Alt A: If always-on SSB is CD-SSB and
not on a synchronization raster, the frequency
location of on-demand SSB can be same or different from the frequency location of always-on SSB, subject to its configuration.
- Alt B: If always-on SSB is CD-SSB and
not on a synchronization raster, the frequency
location of on-demand SSB is the same as the frequency location of always-on SSB
- Alt C: Do not support the case where always-on SSB is CD-SSB
and not on a synchronization raster.
R1-2410782 Summary #4 of on-demand SSB for NES Moderator (LG
Electronics)
From Friday session
Agreement
Response to Q2 (What is the relation in
terms of time location between always-on SSB and OD-SSB?) of Obj.1:
- RAN1 understands
the time location of OD-SSB in Q2 refers to the time location of possible
OD-SSB burst
- RAN1 is still
discussing the relation in terms of time location between always-on SSB
and OD-SSB
Agreement
For a cell
supporting on-demand SSB SCell operation, support
at least the following options to deactivate on-demand SSB transmission from a
UE perspective.
- Option 1: Explicit indication of deactivation for
on-demand SSB via MAC-CE for on-demand SSB transmission indication
- Deactivation by RRC is up to RAN2
- FFS: Which scenario Option 1 is used
- Option 2: Configuration/indication of the number
N of on-demand SSB bursts to be transmitted after on-demand SSB is
indicated
- FFS: Whether Option 4, 4a is needed in addition
to Option 2
- FFS: Whether the value of N can be implicitly
determined using a timer
Final summary in R1-2410912.
R1-2409414 Discussion on on-demand SIB1 for eNES Huawei, HiSilicon
R1-2409518 Discussion on on-demand SIB1 for UEs in idle/inactive mode CMCC
R1-2409545 Discussion on on-demand SIB1 for idle/inactive mode UEs Panasonic
R1-2409557 Discussion on on-demand SIB1 for NES ZTE Corporation,
Sanechips
R1-2409603 On-demand SIB1 for idle/inactive mode UEs Samsung
R1-2409642 Discussion on on-demand SIB1 for idle/inactive mode UEs Spreadtrum,
UNISOC
R1-2409687 Discussions on on-demand SIB1 for idle/inactive mode UEs vivo
R1-2409711 Discussion on on-demand SIB1 for idle/inactive mode UEs KT
Corp.
R1-2409713 On-demand SIB1 for Idle/Inactive mode UEs Nokia,
Nokia Shanghai Bell
R1-2409736 Discussion on-demand SIB1 for idle/inactive mode UEs Intel
Corporation
R1-2409755 On demand SIB1 Tejas Networks Limited
R1-2409773 Discussion on on-demand SIB1 for idle/inactive mode UEs InterDigital,
Inc.
R1-2409809 On On-demand SIB1 for IDLE/INACTIVE mode UEs Apple
R1-2409902 Discussion on on-demand SIB1 for idle/inactive mode UEs Xiaomi
R1-2409947 Discussion on on-demand SIB1 CATT
R1-2409966 Discussion on on-demand SIB1 transmission for idle/inactive
mode UEs Transsion Holdings
R1-2410033 Discussion of on-demand SIB1 for idle/inactive mode UEs FUTUREWEI
R1-2410075 Discussion on the enhancement to support on demand SIB1 for
idle/inactive mode UE OPPO
R1-2410132 Discussion on on-demand SIB1 transmission for network
energy savings Fujitsu
R1-2410157 On-demand SIB1 for Idle/Inactive Mode UE Google
R1-2410210 Discussion on on-demand SIB1 for UEs in idle/inactive mode NEC
R1-2410229 On-demand SIB1 for idle/inactive mode UEs Sony
R1-2410253 On-demand SIB1 for idle/inactive mode UEs Lenovo
R1-2410272 On-demand SIB1 for idle/inactive mode UEs ETRI
R1-2410292 On-demand SIB1 for idle/inactive mode UEs LG
Electronics
R1-2410301 Views on On-demand SIB1 operation for idle/inactive UEs Vodafone,
Deutsche Telekom
R1-2410350 Discussion on on-demand SIB1 for idle/inactive mode UEs DENSO
CORPORATION
R1-2410361 Discussion on on-demand SIB1 transmission for idle UEs Sharp
R1-2410368 Discussion on on-demand SIB1 in idle/inactive mode CAICT
R1-2410395 Discussion on on-demand SIB1 for idle/inactive mode UEs NTT
DOCOMO, INC.
R1-2410442 On-demand SIB1 for UEs in idle/inactive mode for NES Ericsson
R1-2410484 On-demand SIB1 procedure Qualcomm Incorporated
R1-2410522 On-demand SIB1 for idle or inactive mode UEs MediaTek
Inc.
R1-2410561 On-demand SIB1 for NES Fraunhofer IIS, Fraunhofer HHI
R1-2410582 Discussion on on-demand SIB1 CEWiT
R1-2410677 FL summary 1 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From
Tuesday session
Agreement
For
parameters agreed for UL WUS, whether it is mandatory or optional is for
further discussion.
Agreement
At
least for RO validation determination for WUS transmission, the parameter “ssb-PeriodicityServingCell” is included in the
UL-WUS configuration at least for TDD system.
·
FFS: FDD system
Agreement
Confirm
the working assumption below from RAN1 #118-bis to include it in the UL-WUS
configuration.
·
(working assumption) ULSubCarrierSpacing
Agreement
CORESET0
of NES cell is used for RAR CORESET of that NES cell.
Agreement
At
least for the case where SSB is transmitted on sync-raster, the indication of the
quantity K_SSB (defined
in TS 38.211 as subcarrier offset from subcarrier 0 in common resource block 
to the lowest-numbered
subcarrier of the SS/PBCH block) is included in the UL-WUS configuration for
FDD and TDD NES cell.
R1-2410678 FL summary 2 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Wednesday session
Agreement
The
parameter “n-TimingAdvanceOffset” is included in the
UL-WUS configuration.
Agreement
The
reference time point to determine the window starting time for on-demand SIB1
is based on the RAR window for UL WUS wherein UE successfully received a RAR.
·
FFS: Use starting or ending
slot of the RAR window as reference time
Agreement
The
duration of the time window for on-demand SIB1 is indicated in the UL WUS
configuration.
·
Unit of the duration is in slot
·
FFS: Starting time
R1-2410679 FL summary 3 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Thursday session
Agreement
On
how to use
PDCCH-ConfigSIB1 for R19 NES-capable UE in MIB of NES Cell when K_SSB = 30 in
FR1 or K_SSB = 14 in FR2 on NES cell if SSB of NES cell is on the sync raster,
down-select from the following options:
-
Option
1: Use it to indicate frequency assistance information to search SSB for Cell A
o
FFS:
Details on the range/granularity of the frequency assistance information
o
FFS:
Potential impact to RAN3
-
Option
2: Use it to indicate
searchSpaceZero
and controlResourceSetZero of OD-SIB1
-
Option
3: Above feature is not supported.
R1-2410680 FL summary 4 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From
Friday session
Agreement
At
least the contents of RAR in response to SI request are included in RAR in
response to UL WUS.
Conclusion
There
is no RAN1 consensus to support UL WUS repetition in Rel-19.
Agreement
The
mapping rule between ra-PreambleStartIndex for OD-SIB1 and SSB follows
the mapping rule between ra-PreambleStartIndex for OSI request and SSB
as in legacy specification.
Final summary in R1-2410681.
R1-2409415 On common channel/signal adaptation for eNES Huawei,
HiSilicon
R1-2409470 Adaptation of common signal/channel transmissions Quectel
R1-2409519 Discussion on adaptation of common signal/channel
transmissions CMCC
R1-2409558 Discussion on common signal/channel for NES ZTE
Corporation, Sanechips
R1-2409604 Adaptation of common signal/channel transmissions Samsung
R1-2409643 Discussion on adaptation of common signal/channel
transmissions Spreadtrum, UNISOC
R1-2409688 Discussions on adaptation of common signal/channel
transmissions vivo
R1-2409714 Adaptation of common signal/channel transmissions Nokia,
Nokia Shanghai Bell
R1-2409737 Discussion on adaptation of common signal/channel
transmission Intel Corporation
R1-2409756 Adaptation of common signals/channels Tejas Networks
Limited
R1-2409774 Discussion on adaptation of common signal/channel
transmissions InterDigital, Inc.
R1-2409810 On adaptation of common signal/channel for NES enhancements Apple
R1-2409903 Discussion on adaptation of common signal and channel
transmissions Xiaomi
R1-2409948 Discussion on adaptation of common signal/channel
transmissions CATT
R1-2409967 Discussion on adaptive transmission of common signal or
common channel Transsion Holdings
R1-2410005 Discussion on common signal/channel adaptation China
Telecom
R1-2410034 Discussion of the adaptation of common signal/channel
transmissions FUTUREWEI
R1-2410076 Discussion on adaptation of common signal/channel
transmission OPPO
R1-2410134 Discussion on adaptation of common signal / channel
transmissions Fujitsu
R1-2410158 Adaptation of Common Signals Google
R1-2410180 Discussion on adaptation of common signal channel
transmissions HONOR
R1-2410211 Discussion on adaptation of common signal/channel
transmissions NEC
R1-2410230 Adaptation of common signal/channel transmissions Sony
R1-2410247 Discussion on adaptation of common signal/channel
transmission Panasonic
R1-2410273 Adaptation of common signal/channel transmissions ETRI
R1-2410293 Adaptation of common signal/channel transmissions LG
Electronics
R1-2410302 Adaptation of common signals and channels Lenovo
R1-2410362 Discussion on adaptation of common signal/channel
transmissions Sharp
R1-2410396 Discussion on adaptation of common signal/channel
transmissions NTT DOCOMO, INC.
R1-2410443 Adaptation of common signal/channel transmissions for NES Ericsson
R1-2410485 Adaptation of common channel transmissions Qualcomm
Incorporated
R1-2410523 Adaptation of common signal/channel transmissions MediaTek
Inc.
R1-2410583 Discussion on adaptation of common signal and channel
transmissions CEWiT
From AI 5
R1-2409350 LS on SSB relation in On-demand SSB and SSB adaptation on
Scell RAN4, Ericsson
Decision: Response
needed – Ajit (Ericsson).
R1-2410784 Summary#1 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Tuesday session
Agreement
Reply to Q1(What is the relation in terms
of time location before and after SSB adaptation?):
·
RAN1 agreed that at least
SSB burst periodicity is adapted.
·
There are no RAN1
agreements to adapt the time location of the SSB burst other than the
periodicity but RAN1 is still discussing other options.
Agreement
Reply to Q2(What is the relation in terms
of frequency location before and after SSB adaptation?):
·
The frequency location is
same before and after SSB adaptation.
Agreement
Reply to Q3(What is the spatial relation
before and after SSB adaptation?):
- There is no change to spatial relation
(in terms of QCL assumption) for the same SSB index before and after SSB
adaptation.
- At least the case where there is no
change to actually transmitted SSBs within a burst before and after SSB
adaptation is supported.
Further update to be made based on RAN1#119 progress if any.
Agreement
At least msg1-FrequencyStart can be configured separately for the
additional PRACH resources at least for 4-step RACH.
Agreement
For
DCI-based adaptation for additional PRACH resources, select only from the
following alternatives:
- Alt
1: (PRACH resource configuration level) DCI-based adaptation to indicate
whether the additional PRACH resources provided by semi-static signalling
are available or not
- Alt
2: (subset of PRACH resource level) DCI-based adaptation to indicate
whether a subset of the additional PRACH resources provided by
semi-static signalling are available or not
- FFS:
Maximum number of subsets of the additional PRACH resources= [2 or 3 or 4
or 16]
- FFS: whether
the subset of the additional PRACH resources is in
§ Alt 2-1: RO level per
SSB
§ Alt 2-2: SSB-to-RO
mapping cycle level
§ Alt 2-3: PRACH
association period level
§ Alt 2-4: PRACH
association pattern period level
§ Alt 2-5: SFN level
§ Alt 2-6: Network
configured time period
Alt
3: DCI-based
Enhanced/new Cell DRX to indicate whether the enhanced/new Cell DRX is
activated or deactivated.
If
activated, the additional configured PRACH provided by semi-static
signalling within non-active period are not available.FFS:
whether Alt 1 and/or Alt 2 can be applied to the active periodFFS:
details
R1-2410785 Summary#2 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Wednesday session
Conclusion
There
is no RAN1 consensus to support SSB adaptation in time domain for Rel-19
NES-capable UE’s PCell (connected mode).
Working Assumption
For DCI-based adaptation
for additional PRACH resources,
- Select from the
following options for carrying the adaptation indication in DCI format 1_0
with P-RNTI
- Option 1: Use
reserved bits in the DCI format
- FFS: relation (if
any) to TRS availability bits / short message indicator in the DCI
format
- Option 2: Use Bits
5-8 within the Short Message (from upper layers)
- Note:
Availability should be confirmed by checking with RAN2.
- Option 3: Use bits
available for both Option 1 and Option 2
FFS: Payload size for adaptation for
additional PRACH resources
R1-2410786 Summary#3 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Thursday session
Agreement
For
DCI-based adaptation for additional PRACH resources, select only from the
following alternatives:
- Alt
1: DCI-based adaptation to indicate whether the additional PRACH resources
provided by semi-static signalling are available or not
- [DCI
payload size = 1 bit]
o
FFS:
A single PRACH mask provided by semi-static signalling is used to identify the
subset of the additional PRACH resources
R1-2410887 Summary#4 of AI
9.5.3 for R19 NES Moderator(Ericsson)
From Friday session
Agreement
Confirm the following
working assumption from RAN1#118bis.
Working Assumption
For
DCI-based adaptation for additional PRACH resources, at least
DCI format 1_0 can carry the adaptation indication for UEs in idle/inactive and
connected mode.
·
P-RNTI is used
Final
summary in R1-2410888.
Please refer to RP-242354 for detailed scope of
the WI. Additional RAN guidance on Rel-19 NES can be found in RP-243297.
Rapporteur to provide initial input on
higher layer signalling under agenda item 9.5. For input on higher layer
signalling from any other source, please include it as part of your tdoc to
relevant sub-agenda items.
[120-R19-NES] – Ajit (Ericsson)
Email discussion on Rel-19 NES enhancement
-
To be used for sharing updates on
online/offline schedule, details on what is to be discussed in online/offline
sessions, tdoc number of the moderator summary for online session, etc
R1-2501248 List of RAN1 agreements for R19 NES WI until RAN1#119 Rapporteur(Ericsson)
R1-2501249 Initial list of RRC parameters for R19 NES WI Rapporteur(Ericsson)
R1-2501647 Updated list of RAN1 agreements for Rel-19 NES WI Rapporteur
(Ericsson)
R1-2500053 Discussion of on-demand SSB Scell operation FUTUREWEI
R1-2500077 On-demand SSB SCell operation for eNES Huawei, HiSilicon
R1-2500128 Discussion on on-demand SSB for NES ZTE Corporation,
Sanechips
R1-2500173 Discussion on on-demand SSB SCell operation Spreadtrum,
UNISOC
R1-2500228 Discussion on on-demand SSB SCell operation CATT
R1-2500263 Discussion on on-demand SSB operation for SCell China
Telecom
R1-2500291 Discussion on on-demand SSB SCell operation CMCC
R1-2500353 Discussion on on-demand SSB Scell operation vivo
R1-2500400 On demand SSB for connected UEs Tejas Networks Limited
R1-2500440 Discussion on the enhancement to support on demand SSB
SCell operation OPPO
R1-2500476 On-demand SSB SCell Operation Nokia, Nokia Shanghai Bell
R1-2500489 Discussion on on-demand SSB SCell operation Panasonic
R1-2500525 Discussion on on-demand SSB SCell operation InterDigital,
Inc.
R1-2500552 On-demand SSB SCell Operation Google
R1-2500621 Discussion on on-demand SSB for SCell operation NEC
R1-2500682 Discussion on On-demand SSB SCell operation KT
Corp.
R1-2500736 Discussion on on-demand SSB SCell operation Xiaomi
R1-2500785 On-demand SSB SCell Operation Apple
R1-2500854 On-demand SSB SCell operation Samsung
R1-2500884 On-demand SSB SCell operation Lenovo
R1-2500913 Discussion on On-demand SSB SCell operation ETRI
R1-2500940 Discussion on on-demand SSB SCell operation Fujitsu
R1-2500953 On-demand SSB SCell operation LG Electronics
R1-2500967 Discussion on On-Demand SSB SCell operation Transsion
Holdings
R1-2501020 On-demand SSB SCell operation MediaTek Inc.
R1-2501123 Discussion of On-demand SSB SCell operation Mavenir
R1-2501160 On-demand SSB operation for Scell Qualcomm
Incorporated
R1-2501186 Discussion on remaining details of on-demand SSB operation
on SCell Sharp
R1-2501206 Discussion on on-demand SSB SCell operation NTT
DOCOMO, INC.
R1-2501233 Discussion on on-demand SSB SCell operation ITRI
R1-2501238 Discussion on on-demand SSB Scell operation for NES TCL
R1-2501242 DCI based signaling for on-demand SSB ASUSTeK
R1-2501251 On-demand SSB SCell operation Ericsson
R1-2501277 Discussion on on-demand SSB Scell operation CEWiT
R1-2501493 Summary #1 of on-demand SSB for NES Moderator (LG
Electronics)
From Tuesday session
Agreement
Regarding
the relation in terms of time location between the always-on SSB and on-demand SSB,
at least for the case when the center frequency locations of always-on SSB and on-demand
SSB are
same, down-select one of the following.
- Alt Time-A: It is not allowed that time
location of an SSB within on-demand SSB burst overlaps with time location
of any SSB within always-on SSB burst.
- NOTE: It is assumed that the periodicity of always-on SSB is equal
to or larger than that of on-demand SSB.
- Alt Time-B: Time-domain locations of always-on SSB are a subset of
time-domain locations of on-demand SSB.
- NOTE: It is assumed that the periodicity of always-on SSB is equal
to or larger than that of on-demand SSB.
- Alt Time-C: The
specification has no restriction with regards to overlapping
R1-2501494 Summary #2 of on-demand SSB for NES Moderator (LG
Electronics)
From Wednesday session
Agreement
- For a cell supporting on-demand SSB SCell
operation, to provide time domain location of
on-demand SSB by RRC,
- For Case #2, adopt Alt A in the previous
RAN1 agreement, i.e.,
- Based on two
parameters, where one is to indicate SFN offset from a reference point
and the other is to indicate half frame index
- The
reference point is SFN which satisfies (SFN index *10) modulo (OD-SSB
periodicity) = 0
- If
SFN offset parameter is NOT configured, UE assumes SFN offset set to 0.
- If
half frame index parameter is NOT configured, UE assumes half frame
index set to 0.
- The
value range of SFN offset is 0 to 15 unless longer periodicity for
on-demand SSB than 160 ms is introduced.
- The
value range of half frame index is 0 or 1.
- FFS:
Whether/how to indicate time offset between always-on SSB and on-demand
SSB (e.g., similar to ssb-TimeOffset)
- By
defining reference point as SFN where AO-SSB burst exists
Agreement
- For a cell supporting on-demand SSB SCell
operation, introduce NEW
higher layer parameter (i.e., od-ssb-config) for on-demand SSB
configuration, for both Case #1 and Case #2.
- For a cell supporting on-demand SSB SCell
operation, introduce NEW
higher layer parameters to configure each of the followings, for both Case
#1 and Case #2.
- Frequency
of the on-demand SSB
(i.e., od-ssb-absoluteFrequency)
- FFS:
Whether this parameter can be absent for Case #2
- SSB
positions within an on-demand SSB burst by using signaling similar to ssb-PositionsInBurst (i.e., od-ssb-PositionsInBurst)
- FFS:
Whether this parameter can be absent for Case #2
- Periodicity
of the on-demand SSB
(i.e., od-ssb-Periodicity)
- Sub-carrier
spacing of the on-demand SSB
(i.e., od-ssbSubcarrierSpacing)
- For
Case #2, this parameter is absent and sub-carrier spagcing of on-demand
SSB is the same as that of always-on SSB.
- Physical
Cell ID of the on-demand SSB
(i.e., od-ssb-physCellId)
- For
Case #2, this parameter is absent and physical cell ID of on-demand SSB
is the same as that of always-on SSB.
- Time
location of
on-demand SSB burst
(i.e., od-ssb-sfn-Offset and od-ssb-halfFrameIndex)
- Downlink
transmit power of on-demand SSB
(i.e., od-ss-PBCH-BlockPower)
- For
Case #2, this parameter is absent and downlink transmit power of
on-demand SSB is the same as that of always-on SSB.
- Number N of on-demand SSB
bursts to be transmitted after on-demand SSB is indicated (i.e., od-ssb-nrofTx)
- FFS:
Which of the above parameters are a list
Agreement
For
RRC based OD-SSB indication, UE expects on-demand SSB is transmitted from the
first on-demand SSB burst after receiving RRC carrying indication of OD-SSB
transmission.
Conclusion
The following combination of scenarios and cases for indicating
OD-SSB are not supported in Rel-19
- Scenario #3A and Case #1
- Scenario #3A and Case #2
Above does not impact discussion on SSB periodicity
adaptation in time domain.
R1-2501495 Summary #3 of on-demand SSB for NES Moderator (LG
Electronics)
From Thursday session
Agreement
Regarding
the relation in terms of frequency location (i.e., center frequency) between
the always-on SSB and on-demand SSB,
- Alt 1: If always-on SSB is CD-SSB on a synchronization
raster, the frequency location of
on-demand SSB is different
from the frequency location of always-on SSB.
- On-demand SSB is not on sync raster
- AO-SSB and OD-SSB are located in the same BWP
- FFS: Additional conditions
- Subject to separate UE capability
- Note: UE is not required to measure both AO-SSB and OD-SSB
R1-2501496 Summary #4 of on-demand SSB for NES Moderator (LG
Electronics)
From Friday session
Agreement
Regarding
the relation in terms of time location between the always-on SSB and on-demand SSB,
- For the case when the center frequency
locations of always-on SSB and on-demand SSB are same,
- Alt Time-C: RAN1
specification has no restriction with regards to overlapping
- From RAN1 perspective,
- Alt Time-C1:
The case that, during OD-SSB transmission, the union of AO-SSB transmission
and OD-SSB transmission has a periodic time domain pattern is supported
(the interval between SSB bursts is even and supported in legacy
specification).
- Alt Time-C2:
The case that, during OD-SSB transmission, the union of AO-SSB transmission
and OD-SSB transmission has a non-periodic time domain pattern is
supported.
- It
is up to RAN4 to define requirements, if any, corresponding to both or
either of Alt Time-C1 or Alt Time-C2
- At least the following is supported: PBCH payload for the same
SSB index (other than SFN index, half frame index) is the same for AO-SSB
and OD-SSB
- FFS:
Whether half frame index is the same or different for AO-SSB and OD-SSB
- For the case when the center frequency locations of always-on SSB
and on-demand SSB are different,
- Alt Time-C: RAN1
specification has no restriction with regards to overlapping
- UE assumes that frequency resources of always-on SSB are not
overlapped with those of on-demand SSB in frequency domain.
- AO-SSB and OD-SSB are located in the same BWP
- FFS: PBCH payload for the same SSB index (other than SFN
index, half frame index) should be the same for AO-SSB and OD-SSB
- NOTE: AO-SSB periodicity is not adapted
Send an LS to RAN4 to inform them of the above agreement.
R1-2501632 Draft
LS on time location of on-demand SSB for Scell LG Electronics
Decision: The draft LS is endorsed. Final version is approved in R1-2501633.
Agreement
For the case where SCell with on demand SSB transmission and cell
with signalling transmission have different numerology, when UE determines time
instance A, the SCS to determine the value of T is down selected
among the following options
- Option 1: the SCS
of the active DL BWP where UE receives MAC CE for on-demand SSB
transmission indication
- Option 2: the
minimum of “the SCS of the active DL BWP where UE receives MAC CE for
on-demand SSB transmission indication” and “the SCS of the active DL BWP where
UE receives on-demand SSB”
- Option 3: the SCS
of the active UL BWP where the UE transmits ACK corresponding to the
MAC-CE for on-demand SSB transmission indication
Final summary in R1-2501635.
R1-2500054 Discussion of on-demand SIB1 for idle/inactive mode UEs FUTUREWEI
R1-2500078 Discussion on on-demand SIB1 for eNES Huawei, HiSilicon
R1-2500129 Discussion on on-demand SIB1 for NES ZTE Corporation,
Sanechips
R1-2500174 Discussion on on-demand SIB1 for idle/inactive mode UEs Spreadtrum,
UNISOC
R1-2500229 Discussion on on-demand SIB1 CATT
R1-2500264 Discussion on on-demand SIB1 for idle/inactive mode UEs China
Telecom
R1-2500292 Discussion on on-demand SIB1 for UEs in idle/inactive mode CMCC
R1-2500354 Discussion on on-demand SIB1 for idle/inactive mode UEs vivo
R1-2500398 On demand SIB1 for idle/inactive UEs Tejas
Networks Limited
R1-2500441 Discussion on the enhancement to support on demand SIB1 for
idle/inactive mode UE OPPO
R1-2500477 On-demand SIB1 for Idle/Inactive mode UEs Nokia,
Nokia Shanghai Bell
R1-2500490 Discussion on on-demand SIB1 for idle/inactive mode UEs Panasonic
R1-2500526 Discussion on on-demand SIB1 for idle/inactive mode UEs InterDigital,
Inc.
R1-2500553 On-demand SIB1 for Idle/Inactive Mode UE Google
R1-2500622 Discussion on on-demand SIB1 for UEs in idle/inactive mode NEC
R1-2500629 Discussion on on-demand SIB1 transmission for network
energy savings Fujitsu
R1-2500654 On-demand SIB1 for idle/inactive mode UEs Sony
R1-2500737 Discussion on on-demand SIB1 for idle/inactive mode UEs Xiaomi
R1-2500786 On On-demand SIB1 for IDLE/INACTIVE mode UEs Apple
R1-2500855 On-demand SIB1 for idle/inactive mode UEs Samsung
R1-2500885 On-demand SIB1 for idle/inactive mode UEs Lenovo
R1-2500914 On-demand SIB1 for idle/inactive mode UEs ETRI
R1-2500954 On-demand SIB1 for idle/inactive mode UEs LG
Electronics
R1-2500968 Discussion on on-demand SIB1 transmission for idle/inactive
mode UEs Transsion Holdings
R1-2501021 On-demand SIB1 for idle or inactive mode UEs MediaTek
Inc.
R1-2501049 Views on On-demand SIB1 for idle-inactive UEs Vodafone
R1-2501089 Discussion on on-demand SIB1 for idle/inactive mode UEs DENSO
CORPORATION
R1-2501133 Discussion on on-demand SIB1 transmission for idle UEs Sharp
R1-2501161 On-demand SIB1 procedure Qualcomm Incorporated
R1-2501207 Discussion on on-demand SIB1 for idle/inactive mode UEs NTT
DOCOMO, INC.
R1-2501252 On-demand SIB1 for UEs in idle/inactive mode for NES Ericsson
R1-2501263 Discussion on on-demand SIB1 in idle/inactive mode CAICT
R1-2501278 Discussion on on-demand SIB1 CEWiT
R1-2501299 On-demand SIB1 for NES Fraunhofer IIS, Fraunhofer HHI
R1-2501378 FL summary 1 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Tuesday session
Agreement
The reference time point to determine the
window starting time for on-demand SIB1 is based on the starting slot of the
RAR window for UL WUS wherein UE successfully received a RAR.
Agreement
The time offset between the reference time
point and the starting time for the time window of on-demand SIB1 is indicated
in the UL WUS configuration.
·
Unit of the time offset is
in slot
R1-2501379 FL summary 2 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From
Wednesday session
Conclusion
On
how to use PDCCH-ConfigSIB1
for R19 NES-capable UE in MIB of NES Cell when K_SSB = 30 in FR1 or K_SSB =
14 in FR2
on NES cell if SSB of NES cell is on the sync raster, Option 3 is adopted.
- Option
1: Use it to indicate frequency assistance information to search SSB for
Cell A
- FFS:
Details on the range/granularity of the frequency assistance information
- FFS:
Potential impact to RAN3
- Option
2: Use it to indicate
searchSpaceZero
and controlResourceSetZero of OD-SIB1
- Option
3: Above feature is not supported.
Agreement
For
type 0 PDCCH monitoring occasions of on demand SIB1, searchSpaceZero and
controlResourceSetZero for on-demand SIB1 are provided from UL WUS
configuration if SSB on NES cell is on sync raster.
Agreement
The UE
assumes that, in the OD-SIB1 window, PDCCH for an OD-SIB1 message is
transmitted in at least PDCCH monitoring occasions corresponding
to at least the SSB associated with the PRACH for UL-WUS if this is indicated
via UL WUS configuration
- FFS:
Whether UE expect PDCCH on PDCCH monitoring occasion corresponding to SSB
other than the one mentioned above
- FFS:
Whether gNB can indicate (in UL-WUS configuration) the SSB the UE can
expect PDCCH transmission on
Conclusion
There
is no RAN1 consensus on the following proposal:
From
RAN1 perspective, OD-SIB1 design does not differentiate depending on frequency
location of SSB on NES cell
R1-2501380 FL summary 3 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Thursday session
Conclusion
It’s up to
RAN2 to discuss whether the value in OD-SIB1 IE can be different from the value
of the corresponding IE in the WUS configuration, and how to define the UE
behavior if the values are different.
Conclusion (amended as shown in
red in Friday session)
- The parameter
“ssb-PeriodicityServingCell” is not included in the UL-WUS configuration
for FDD system.
- RA-RNTI is not included in the UL-WUS
configuration
for FDD system.
- Cell barring information is not included
in the UL-WUS configuration
for FDD system.
- Cell selection information is not
included in the UL-WUS configuration
for FDD
system.
- Accessible UE types is not included in
the UL-WUS configuration
for FDD system.
- CarrierBandwidth (for MPR calculation) is
not included in the UL-WUS configuration
for
FDD system.
- InitialUplinkBWP is not included in the
UL-WUS configuration
for FDD system.
- TotalNumberOfRA-Preambles is not included
in the UL-WUS configuration
for FDD system.
- SIB1-RequestResourceRedCap is not included in the UL-WUS configuration
for FDD system.
- SupplementaryUL is not
included in the UL-WUS configuration
Conclusion
There
is no RAN1 consensus to support the following in Rel-19:
Support
joint PRACH request to trigger both OD-SIB1 and a subset of OD-OSI, e.g.
SIB2/SIB3/SIB4.
- FFS:
parameters in UL-WUS config to support joint PRACH request.
R1-2501381 FL summary 4 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Friday session
Agreement
If a UE has SIB1 request configuration of a
cell and before transmitting UL WUS,
- If the UE detects a SSB where K_SSB>=24 for
FR1 or K_SSB>=13 for FR2,
down select from the following:
- Alt. 1: Only if K_SSB=30 for FR1 and
K_SSB=14 for FR2, UE monitors Type 0 PDCCH for SIB1 transmission;
Otherwise, UE doesn’t monitor Type 0 PDCCH
- FFS: Whether monitoring time window of
Type 0 PDCCH is up to UE implementation or specified.
- Alt. 2: UE monitors Type 0 PDCCH for
SIB1 transmission
- FFS: Whether monitoring time window of
Type 0 PDCCH is up to UE implementation or specified.
- Alt. 3: It is up to UE implementation on
whether to monitor Type 0 PDCCH for SIB1
transmission
- Alt. 4: UE doesn’t monitor Type 0 PDCCH
for SIB1 transmission.
- Alt. 5: UE monitors Type 0 PDCCH for
SIB1 based on some repurposed parameters in MIB or PBCH
Note: If the UE
detects a SSB where K_SSB<=23 for FR1 or K_SSB<=12 for FR2, UE monitors Type 0 PDCCH for SIB1
transmission as legacy.
Note: From Ericsson point view, Alt 3 and
Alt 4 may be inconsistent with existing RAN2 agreements
Note: The above cases are for SSB on the
sync raster.
Final summary in R1-2501382.
R1-2500055 Discussion of the adaptation of common signal/channel
transmissions FUTUREWEI
R1-2500079 On common channel/signal adaptation for eNES Huawei,
HiSilicon
R1-2500130 Discussion on common signal channel for NES ZTE
Corporation, Sanechips
R1-2500175 Discussion on adaptation of common signal/channel
transmissions Spreadtrum, UNISOC
R1-2500230 Discussion on adaptation of common signal/channel
transmissions CATT
R1-2500265 Discussion on common signal/channel adaptation China
Telecom
R1-2500293 Discussion on adaptation of common signal/channel
transmissions CMCC
R1-2500355 Discussion on adaptation of common signal/channel
transmissions vivo
R1-2500399 Adaptation of common signals/channels Tejas Networks
Limited
R1-2500442 Discussion on adaptation of common signal/channel
transmission OPPO
R1-2500478 Adaptation of common signal/channel transmissions Nokia,
Nokia Shanghai Bell
R1-2500527 Discussion on adaptation of common signal/channel
transmissions InterDigital, Inc.
R1-2500554 Adaptation of Common Signals Google
R1-2500623 Discussion on adaptation of common signal/channel
transmissions NEC
R1-2500630 Discussion on adaptation of common signal / channel
transmissions Fujitsu
R1-2500655 Adaptation of common signal/channel transmissions Sony
R1-2500683 Discussion on Adaptation of common signal/channel
transmissions KT Corp.
R1-2500738 Discussion on adaptation of common signal and channel
transmissions Xiaomi
R1-2500787 On adaptation of common signal/channel for NES enhancements Apple
R1-2500856 Adaptation of common signal/channel transmissions Samsung
R1-2500915 Adaptation of common signal/channel transmissions ETRI
R1-2500946 Discussion on adaptation of common signal/channel
transmission Panasonic
R1-2500955 Adaptation of common signal/channel transmissions LG
Electronics
R1-2500969 Discussion on adaptive transmission of common signal or
common channel Transsion Holdings
R1-2501022 Adaptation of common signal/channel transmissions MediaTek
Inc.
R1-2501053 Adaptation of common signals and channels Lenovo
R1-2501112 Discussion on adaptation of common signal channel
transmissions HONOR
R1-2501134 Discussion on adaptation of common signal/channel
transmissions Sharp
R1-2501162 Adaptation of common channel transmissions Qualcomm
Incorporated
R1-2501208 Discussion on adaptation of common signal/channel
transmissions NTT DOCOMO, INC.
R1-2501253 Adaptation of common signal/channel transmissions for NES Ericsson
R1-2501279 Discussion on adaptation of common signal and channel
transmissions CEWiT
R1-2501451 Summary#1 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Tuesday session
Agreement
For adaptation of PRACH in time-domain, for
determining the additional PRACH resources in time-domain,
·
When an additional RO is overlapped
with legacy valid RO in both time and frequency domain, the additional RO is
invalid before the SSB-RO mapping
o
Note: the overlapped RO for
legacy resource is not impacted
o
FFS: Clarification on
configuration of legacy ROs
Conclusion
There
is no RAN1 consensus to support the following in Rel-19
- New SSB burst
periodicity values other than the legacy values (i.e., 5 ms, 10 ms, 20 ms,
40 ms, 80 ms, or 160 ms).
- New UE trigger
- Adapting the
transmitted number of SSBs within a SSB burst
- Adaptation of the
time domain positions of SSBs within a burst
Conclusion
There is no RAN1 consensus to support time
domain adaptation for CD-SSB in Rel-19 for SCell.
R1-2501452 Summary#2 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Wednesday session
Agreement
For adaptation of SSB in time-domain, support the
following to adapt SSB burst periodicity for an SCell
- UE is configured
with SSB burst periodicity using legacy signalling for the SCell
- UE is configured
with X additional SSB burst periodicity for the SCell
- SSB occasions with
larger periodicity are subset of the SSB occasions with shorter
periodicity
- FFS: Whether there
is specification impact
- Note: This does
not impact the discussion on OD-SSB
- For switching the
periodicity, down-select between
- (MAC-CE)
- MAC-CE details
for SSB burst periodicity adaptation is up to RAN2.
- (DCI)
- Alt 1-3: DCI
based signalling is used
Agreement
For
adaption of PRACH in time-domain, for a connected mode UE, support a 1-bit
field in DCI 1_0 with C-RNTI used to trigger PRACH (i.e. PDCCH order) to
indicate whether the additional PRACH resource(s) is available for the
triggered PRACH.
- FFS:
UE behaviour (e.g. applicable resources for PRACH mask index) when it is
indicated of additional PRACH resource(s)
- FFS:
Details on how to reuse existing bit for the 1-bit indication
Agreement
For
DCI-based adaptation for additional PRACH resources, DCI 1_0 with P-RNTI
indicates the availability information for additional PRACH resource from a
reference point and for a validity time duration
- FFS:
Validity time duration for availability is configured by higher layer
signaling or predefined
- FFS:
Location of the reference point defined in the specification
- FFS:
Value/granularity of the validity time duration.
- FFS:
Whether DCI can be used to explicitly deactivate the additional PRACH
resources
R1-2501453 Summary#3 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Thursday session
Agreement
For DCI-based adaptation for additional
PRACH resources, support optional semi-static signalling of a single PRACH mask
to identify the subset of the additional PRACH resources
- The mask is applicable at unit of
- Alt 1: PRACH association period
- Alt 2: PRACH association pattern period
- Alt 3: SFN level
- The PRACH association period is
determined based on valid additional ROs only.
- The mask is applied after valid RO
determination and SSB-RO mapping.
- Note: The existing behaviour in TS 38.213
"An association pattern period includes one or more association
periods and is determined so that a pattern between PRACH occasions and
SS/PBCH block indexes repeats at most every 160 msec." is not impacted
due to application of the mask.
- This is applicable at least for
adaptation for DCI 1_0 with P-RNTI
- The DCI does not indicate PRACH mask
selection
- FFS: how the mask is identified
- Option 1: The PRACH mask is from a PRACH
mask table
- Pre-defined table with N=[4 or 8 or 16]
rows
- The semi-static signalling indicates a
PRACH mask index
- Option 2: The PRACH mask is based on
configuration parameters e.g. bitmap at SFN-level, periodic time domain
window, …
Agreement
- Separate configuration of Msg1-FDM for
the additional PRACH resources at least for 4-step RACH is supported
- UE is not expected to be configured such
that there are more than 8 FDM-ed valid ROs (legacy + additional ROs)
- FFS: When there is no configuration of
Msg1-FDM
- Separate configuration of number of SSB
per RO is supported
R1-2501599 Summary#4 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Friday session
Agreement
Study
the following options for the reference point (for the availability information
of additional PRACH resources indicated by DCI 1_0 with P-RNTI in a PF) for RRC idle/inactive mode UE and RRC
connected mode UE,
- Option
1: SFN of the first PF from the next I-DRX cycle
- Option
2: SFN of the first PF from the current I-DRX cycle
- Option
3: From the first frame of the first PRACH association period after UE
receives the DCI
- Option
4: From the first frame of the current SI modification period
- Option
5: From the first frame of the next SI modification period
Agreement
For
adaptation of SSB in time-domain, for adapting SSB burst periodicity for an
SCell
- Support group
common DCI signalling for switching the SSB burst periodicity using DCI
format 2_9 with [cellDTRX-RNTI]
- FFS: which
scenario(s) is this applicable for (e.g. as defined in 9.5.1)
Note: Above does not
prevent RAN2 from designing a MAC CE based on OD-SSB feature and also used for
SSB burst adaptation
R1-2501600 Final Summary of AI 9.5.3 for R19 NES Moderator
(Ericsson)
Please refer to RP-250343 for detailed scope of
the WI. Additional RAN guidance on Rel-19 NES can be found in RP-243297.
[120bis-R19-NES] – Ajit (Ericsson)
Email discussion on Rel-19 NES enhancement
-
To be used for sharing updates on
online/offline schedule, details on what is to be discussed in online/offline
sessions, tdoc number of the moderator summary for online session, etc
R1-2502801 Update of RAN1 RRC parameter list for R19 NES WI Rapporteur(Ericsson)
R1-2503145 Summary of the discussion on RAN1 RRC parameter list for
R19 NES Rapporteur (Ericsson)
R1-2503126 Updated list of RAN1 agreements for Rel-19 NES WI Rapporteur
(Ericsson)
R1-2501713 Discussion of on-demand SSB Scell operation FUTUREWEI
R1-2501736 On-demand SSB Scell operation for NES TCL
R1-2501764 Discussion on on-demond SSB for NES ZTE Corporation,
Sanechips
R1-2501772 On-demand SSB SCell Operation Nokia, Nokia Shanghai Bell
R1-2501810 Discussions on on-demand SSB Scell operation vivo
R1-2501872 Discussion on on-demand SSB SCell operation Spreadtrum,
UNISOC
R1-2501952 On-demand SSB SCell Operation Google
R1-2501996 Discussion on on-demand SSB SCell operation CATT
R1-2502010 OD-SSB for SCELL Tejas Network Limited
R1-2502026 Discussion on on-demand SSB operation for SCell China
Telecom
R1-2502044 Discussion on on-demand SSB SCell operation Ofinno
R1-2502092 Discussion on on-demand SSB SCell operation KT
Corp.
R1-2502127 Discussion on on-demand SSB SCell operation Fujitsu
R1-2502164 Discussion on on-demand SSB SCell operation CMCC
R1-2502198 Discussion on on-demand SSB for SCell
operation NEC Late submission
R1-2502229 On-demand SSB SCell operation for eNES Huawei, HiSilicon
R1-2502261 Discussion on the enhancement to support on demand SSB
SCell operation OPPO
R1-2502334 Discussion on on-demand SSB SCell operation InterDigital,
Inc.
R1-2502372 On-demand SSB SCell operation Samsung
R1-2502403 Discussion on remaining details of on-demand SSB operation
on SCell Sharp
R1-2502445 Discussion on on-demand SSB SCell operation Xiaomi
R1-2502478 On-demand SSB SCell operation LG Electronics
R1-2502513 Discussion on On-demand SSB SCell operation ETRI
R1-2502542 Discussion on On-Demand SSB SCell operation Transsion
Holdings
R1-2502569 On-demand SSB SCell operation Lenovo
R1-2502578 Discussion on on-demand SSB SCell operation Panasonic
R1-2502612 On-demand SSB SCell Operation Apple
R1-2502679 DCI based signaling for on-demand SSB ASUSTeK
R1-2502708 On-demand SSB SCell operation MediaTek Inc.
R1-2502770 Discussion on on-demand SSB SCell operation NTT
DOCOMO, INC.
R1-2502796 Discussion on on-demand SSB SCell operation ITRI
R1-2502802 On-demand SSB SCell operation Ericsson
R1-2502843 On-demand SSB operation for Scell Qualcomm
Incorporated
R1-2502917 Discussion on on-demand SSB Scell operation CEWiT
R1-2503045 Summary #1 of on-demand SSB for NES Moderator (LG
Electronics)
From Tuesday session
Agreement
For the case where SCell
with on demand SSB transmission and cell with signalling transmission have
different numerology, adopt Option 3 to determine SCS for 
for determining T.
- Option 3: The SCS
of the active UL BWP where the UE transmits ACK corresponding to the
MAC-CE for on-demand SSB transmission indication.
Agreement
For the case when
the center frequency locations
of always-on SSB and on-demand SSB
are different,
at least the following is supported for QCL between AO-SSB and OD-SSB:
·
SS/PBCH blocks with the same SSB indexes for always-on SSB and on-demand SSB are quasi co-located with respect to Doppler
spread, Doppler shift, average gain, average delay, delay spread, and when
applicable, spatial RX parameters.
·
When a signal/channel is
configured to be QCLed with a SSB index, the signal/channel is QCLed with the
same SSB index of always-on SSB and on-demand SSB (if
transmitted) with the same QCL parameters according to existing specifications.
R1-2503046 Summary #2 of on-demand SSB for NES Moderator (LG
Electronics)
From Wednesday session
Agreement
For a cell supporting on-demand SSB SCell
operation, for configuring the number N of on-demand SSB bursts to be
transmitted after on-demand SSB is indicated (i.e., od-ssb-nrofBurst),
·
Alt 2: The value range of od-ssb-nrofBurst
is {N2 integer values}.
o
N2= [8].
o
If od-ssb-nrofBurst
for an on-demand SSB is NOT configured, the on-demand SSB is deactivated via
MAC CE.
o
If od-ssb-nrofBurst
for an on-demand SSB is configured, the on-demand SSB is deactivated based on
the configured value for od-ssb-nrofBurst [or via MAC CE].
Agreement
Upon the reception of MAC CE for deactivating
on-demand SSB, UE expects that on-demand SSB is NOT transmitted from time
instance B.
- Time instance B’ is
T slots after the slot where UE receives a signalling from gNB to deactivate
on-demand SSB. If time instance B’ falls within an on-demand SSB burst,
time instance B is the ending of the slot containing the last actually
transmitted SSB index within the on-demand SSB burst, otherwise, time
instance B = time instance B’.
- As agreed in
previous RAN1 meeting, the SSB time domain positions of on-demand SSB
burst are configured by gNB.
- As agreed in
previous RAN1 meeting, the location(s) (e.g., SFN offset, half frame
index) in the time domain of “possible” on-demand SSB burst and SSB
position within the burst should be configured by the gNB
- (Working
assumption)
T is not less than T_min=
+1 where slot n+m
is a
slot indicated for PUCCH transmission with HARQ-QCK information when the
UE receives MAC CE signaling to deactivate on-demand SSB ending in slot n, and is as defined in current
specification.
- (Working
assumption)
T=T_min
- RAN4 to confirm
the above two working assumptions
- is based on the SCS of the
active UL BWP where the UE transmits ACK corresponding to the MAC-CE for
on-demand SSB transmission indication
R1-2503047 Summary #3 of on-demand SSB for NES Moderator (LG
Electronics)
From Thursday session
Agreement
For a cell
supporting on-demand SSB SCell operation, at least for the
following parameter(s) (in addition to agreed ones), multiple candidate values
can be configured (includes the case where no candidate values are configured)
by RRC and the applicable value can be indicated by MAC CE for on-demand SSB
transmission indication for the cell.
- SSB
positions within an on-demand SSB burst by using signaling similar to ssb-PositionsInBurst (i.e., od-ssb-PositionsInBurst)
for the following cases
- The
case where center frequency of AO-SSB and OD-SSB are different
- Case
1
- Number N of
on-demand SSB bursts to be transmitted after on-demand SSB is indicated (i.e., od-ssb- nrofBurst)
FFS:
Additional restrictions
R1-2503096 DRAFT LS to RAN4 on time instance B for
on-demand SSB SCell operation LG Electronics
Thursday
decision: Draft LS
to RAN4 on time instance B for on-demand SSB SCell operation is endorsed. Final
LS is approved in R1-2503108.
R1-2503048 Summary #4 of on-demand SSB for NES Moderator (LG
Electronics)
From Friday session
Agreement
For a cell supporting on-demand SSB SCell
operation,
- Frequency of the on-demand SSB (i.e., od-ssb-absoluteFrequency)
can be absent for Case #2.
- If absent, the center
frequency of on-demand SSB is the same as that of always-on SSB.
- od-ssb-PositionsInBurst, if provided, has the same
bitmap structure as ssb-PositionsInBurst provided in ServingCellConfigCommon, that is od-ssb-PositionsInBurst is choice of 4-bit shortBitmap,
8-bit mediumBitmap, or 64-bit longBitmap.
- od-ssb-PositionsInBurst can be absent for Case #2.
- If absent, od-ssb-PositionsInBurst
is the same as ssb-PositionsInBurst provided in ServingCellConfigCommon.
Agreement
For a cell supporting on-demand SSB SCell
operation, the following
combinations of scenarios and cases are supported for indicating OD-SSB using a
MAC-CE.
- Scenario #3B and Case #1
- In the above combinations of scenarios and cases, the MAC-CE is used only
for updating the transmission parameter of a transmitted OD-SSB for the
cell since the OD-SSB has been transmitted according to NW indication.
- Scenario #3B and Case #2
- In the above combinations of scenarios and cases, the MAC-CE
is used only for updating the transmission parameter of a transmitted
OD-SSB for the cell since the OD-SSB has been transmitted according to NW
indication.
Agreement
For a cell supporting on-demand SSB SCell
operation, for Case #1 (i.e., No always-on SSB on the
cell)
- UE does not expect the OD-SSB transmission indicated by
RRC/MAC-CE to be deactivated while the SCell is activated.
Agreement
For a cell supporting on-demand SSB SCell
operation and for Case #2 (i.e., Always-on SSB is periodically transmitted on the cell),
- A CSI report configuration can be associated with
- both of AO-SSB and OD-SSB
- Which SSB to measure is up to UE implementation as long as
RAN4 requirements are met.
- Applies at least for the case where AO-SSB
and OD-SSB have the same center frequency and
the same positions in the same SSB burst.
- FFS: It is up to UE to measure both SSBs or one of them if
the higher layer timeRestrictionForChannelMeasurements in CSI-ReportConfig
is set to “Configured”.
- OD-SSB only
- FFS: Applies at least for the case where AO-SSB and OD-SSB have the different
center frequencies.
Final summary in R1-2503119.
R1-2501714 Discussion of on-demand SIB1 for idle/inactive mode UEs FUTUREWEI
R1-2501765 Discussion on on-demand SIB1 for NES ZTE Corporation,
Sanechips
R1-2501773 On-demand SIB1 for Idle/Inactive mode UEs Nokia,
Nokia Shanghai Bell
R1-2501811 Discussions on on-demand SIB1 for idle/inactive mode UEs vivo
R1-2501873 Discussion on on-demand SIB1 for idle/inactive mode UEs Spreadtrum,
UNISOC
R1-2501953 On-demand SIB1 for Idle/Inactive Mode UE Google
R1-2501997 Discussion on on-demand SIB1 CATT
R1-2502027 Discussion on on-demand SIB1 for idle/inactive mode UEs China
Telecom
R1-2502045 Discussion on on-demand SIB1 for idle/inactive mode UEs Ofinno
R1-2502128 Discussion on on-demand SIB1 transmission for network
energy savings Fujitsu
R1-2502165 Discussion on on-demand SIB1 for UEs in idle/inactive mode CMCC
R1-2502199 Discussion on on-demand SIB1 for UEs in
idle/inactive mode NEC Late submission
R1-2502230 Discussion on on-demand SIB1 for eNES Huawei, HiSilicon
R1-2502262 Discussion on the enhancement to support on demand SIB1 for
idle/inactive mode UE OPPO
R1-2502321 On-demand SIB1 for idle/inactive mode UEs Sony
R1-2502335 Discussion on on-demand SIB1 for idle/inactive mode UEs InterDigital,
Inc.
R1-2502373 On-demand SIB1 for idle/inactive mode UEs Samsung
R1-2502446 Discussion on on-demand SIB1 for idle/inactive mode UEs Xiaomi
R1-2502469 OD-SIB1 for Idle/Inactive UEs Tejas Network Limited
R1-2502479 On-demand SIB1 for idle/inactive mode UEs LG
Electronics
R1-2502514 On-demand SIB1 for idle/inactive mode UEs ETRI
R1-2502543 Discussion on on-demand SIB1 transmission for idle/inactive
mode UEs Transsion Holdings
R1-2502570 On-demand SIB1 for idle/inactive mode UEs Lenovo
R1-2502579 Discussion on on-demand SIB1 for idle/inactive mode UEs Panasonic
R1-2502613 On On-demand SIB1 for IDLE/INACTIVE mode UEs Apple
R1-2502658 On-demand SIB1 for NES Fraunhofer IIS, Fraunhofer HHI
R1-2502678 Remaining details for OD-SIB1 request ASUSTeK
R1-2502681 Discussion on on-demand SIB1 transmission for idle UEs Sharp
R1-2502709 On-demand SIB1 for idle or inactive mode UEs MediaTek
Inc.
R1-2502750 Discussion on on-demand SIB1 for idle/inactive mode UEs DENSO
CORPORATION
R1-2502771 Discussion on on-demand SIB1 for idle/inactive mode UEs NTT
DOCOMO, INC.
R1-2502803 On-demand SIB1 for UEs in idle/inactive mode for NES Ericsson
R1-2502844 On-demand SIB1 procedure Qualcomm Incorporated
R1-2502918 Discussion on on-demand SIB1 CEWiT
R1-2502921 Discussion on on-demand SIB1 in idle/inactive mode CAICT
R1-2503004 FL summary 1 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Tuesday session
Conclusion
There is
no RAN1 consensus to support SSB with on-demand SIB1 not on sync raster.
Agreement
The
following agreement is updated as follows:
The UE
assumes that, in the OD-SIB1 window, PDCCH for an OD-SIB1 message is
transmitted in PDCCH monitoring occasions corresponding only to at least the SSB associated with the transmitted
PRACH for UL-WUS if this is indicated via UL WUS configuration by a 1-bit indication.
- If the 1-bit indication is included in UL WUS
config and indicate as TRUE, the UE assumes that, in the OD-SIB1 window, PDCCH for an OD-SIB1 message is transmitted in PDCCH
monitoring occasions
corresponding only to the
SSB associated with the PRACH for UL-WUS.
- If the 1-bit indication is not included in UL WUS
config or the 1-bit indication is FALSE, the UE assumes the same as legacy, i.e., in the
OD-SIB1 window, PDCCH for an OD-SIB1 message is transmitted in at least
one PDCCH monitoring occasion corresponding to each transmitted SSB.
- Further study possible down selection from the
following options to indicate additional information related to SSBs
associated with PDCCH monitoring occasions.
- Alt1: The information is provided in UL-WUS
config
- Alt2: The information is provided in RAR in
response to UL-WUS transmission
- Alt3: No additional information is provided
R1-2503005 FL summary 2 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
R1-2503006 FL summary 3 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Thursday session
Agreement
Indication
of K_SSB value in the UL-WUS configuration should be 5 bits for FR1 and 4 bits
for FR2.
·
Note: there is no change to
current PBCH structure.
·
UE does not expect K_SSB to
be larger than 23 for FR1 and larger than 11 for FR2.
Agreement
The
value of the time offset between the reference time point and the starting time
for the time window of OD-SIB1 can be either 0 or positive value.
Agreement
After
transmitting a UL-WUS, UE
is not required to monitor Type0-PDCCH
occasion (for OD-SIB1)
before UE successfully received its RAR in response to the UL WUS.
Agreement
If
a UE has SIB1 request configuration of a cell and before transmitting UL WUS,
·
If the UE detects a SSB
where K_SSB>=24 for FR1 or K_SSB>=123 for FR2, select the following:
o
Alt. 3: It is up to UE
implementation on whether to monitor Type 0 PDCCH for SIB1 transmission
Agreement
In the UL WUS configuration, how to support multiple NES-CellId(s) is up to
RAN2 discussion.
Agreement
From
RAN1 perspective, for agreed UL WUS parameters, regarding their mandatory or
optional presence and applicability to TDD and/or FDD, adopt the followings:
·
PhysCellId and ARFCN-ValueNR are mandatory
·
frequencyBandList and absoluteFrequencyPointA are present in IE FrequencyInfoUL
for FDD (as in the legacy specification)
·
K_SSB is mandatory
·
searchSpaceZero and controlResourceSetZero are mandatory
·
ra-PreambleStartIndex, od-sib1-duration, offsetToTimeWindow are mandatory
Agreement
The
parameter ra-SearchSpace in the UL-WUS configuration is of type SearchSpace.
Agreement
Replace
the current parameter name offsetToTimeWindow with od-sib1-windowStartOffset
(to make the naming more comprehensive).
R1-2503007 FL summary 4 for on-demand SIB1 in idle/inactive mode Moderator
(MediaTek)
From Friday session
Agreement
Include
CarrierBandwidth and locationAndBandwidth in the UL-WUS
configuration.
·
Previous RAN1 #120
conclusion is reverted
Agreement
The
following previous RAN1 #118-bis agreement is updated as:
- Msg1-FrequencyStart
is with respect to the first RB of the
UE
carrier InitialUplinkBWP determined
by locationAndBandwidth
offsetToCarrier and absoluteFrequencyPointA (same as legacy)
Agreement
RAN1 to discuss the value range for od-sib1-duration.
For example,
- Option 1: Use the value-range for si-windowLength
(from 5 slots to 5120 slot) as starting point.
- Option 2: The duration of the time window
can be a multiple of 160ms (i.e. legacy SIB1 periodicity).
- Option 3: The duration of the time window
can be a multiple of the on-demand SIB1 repetition
periodicity (if supported)
- Other options are not precluded.
Agreement
RAN1 clarifies frequencyBandList in
UL WUS configuration refers to the IE within FrequencyInfoUL-SIB.
Final summary in R1-2503008.
R1-2501715 Discussion of the adaptation of common signal/channel
transmissions FUTUREWEI
R1-2501766 Discussion on common signal channel for NES ZTE
Corporation, Sanechips
R1-2501774 Adaptation of common signal/channel transmissions Nokia,
Nokia Shanghai Bell
R1-2501812 Discussions on adaptation of common signal/channel
transmissions vivo
R1-2501874 Discussion on adaptation of common signal/channel
transmissions Spreadtrum, UNISOC
R1-2501954 Adaptation of Common Signals Google
R1-2501998 Discussion on adaptation of common signal/channel
transmissions CATT
R1-2502028 Discussion on common signal/channel adaptation China
Telecom
R1-2502093 Discussion on adaptation of common signal/channel
transmissions KT Corp.
R1-2502129 Discussion on adaptation of common signal channel
transmissions Fujitsu
R1-2502166 Discussion on adaptation of common signal/channel
transmissions CMCC
R1-2502192 Discussion on adaptation of common signal/channel
transmission Panasonic
R1-2502200 Discussion on adaptation of common
signal/channel transmissions NEC Late submission
R1-2502231 On common channel/signal adaptation for eNES Huawei,
HiSilicon
R1-2502254 Adaptation of common signals and channels Lenovo
R1-2502263 Discussion on adaptation of common signal/channel
transmission OPPO
R1-2502336 Discussion on adaptation of common signal/channel
transmissions InterDigital, Inc.
R1-2502374 Adaptation of common signal/channel transmissions Samsung
R1-2502447 Discussion on adaptation of common signal and channel
transmissions Xiaomi
R1-2502470 Adaptation of common signal/channels Tejas Network
Limited
R1-2502480 Adaptation of common signal/channel transmissions LG
Electronics
R1-2502515 Adaptation of common signal/channel transmissions ETRI
R1-2502544 Discussion on adaptive transmission of common signal or
common channel Transsion Holdings
R1-2502614 On adaptation of common signal/channel for NES enhancements Apple
R1-2502659 Adaptation of Common Signals and Channels for NES Fraunhofer
IIS, Fraunhofer HHI
R1-2502682 Discussion on adaptation of common signal/channel
transmissions Sharp
R1-2502693 Discussion on adaptation of common signal channel
transmissions HONOR
R1-2502710 Adaptation of common signal/channel transmissions MediaTek
Inc.
R1-2502772 Discussion on adaptation of common signal/channel
transmissions NTT DOCOMO, INC.
R1-2502797 Discussion on common signal adaptation KDDI
Corporation
R1-2502804 Adaptation of common signal/channel transmissions for NES Ericsson
R1-2502845 Adaptation of common channel transmissions Qualcomm
Incorporated
R1-2502919 Discussion on adaptation of common signal and channel
transmissions CEWiT
R1-2503052 Summary#1 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Tuesday session
Agreement
(Legacy RO)
For adaptation of PRACH in time-domain, at least for 4-step RACH, at least for DCI 1_0 with P-RNTI,
- Support
configuration of the additional PRACH resources within [the same]
RACH-ConfigCommon in SIB1 used to configure the legacy PRACH resources
- the legacy PRACH
resources used for ‘additional RO validation before the SSB-RO mapping’
are configured in the RACH-ConfigCommon.
Agreement
(Bit in DCI P-RNTI)
For DCI-based adaptation
for additional PRACH resources, the following 1-bit field is used for
adaptation indication in DCI format 1_0 with P-RNTI
·
Use one bit from the Bits
5-8 within the Short Message field (from upper layers).
·
Send LS to RAN2 to confirm
the use of this bit.
Above applies for cell
that transmits the DCI for connected UEs and IDLE/INACTIVE mode UEs.
Agreement
(Validity
duration)
For DCI-based adaptation
for additional PRACH resources, for the availability information of additional
PRACH resources indicated by DCI 1_0 with P-RNTI:
·
the validity duration is
configured via higher layer signalling.
Agreement
(Unit of
PRACH subset mask)
For DCI-based
adaptation for additional PRACH resources, PRACH mask that identifies the
subset of the additional PRACH resources is applicable at unit of
·
PRACH association period.
·
This PRACH mask applies to
every [configured] K SSB RO association pattern period(s).
R1-2503053 Summary#2 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Wednesday session
Agreement
For
adaptation of SSB in time-domain, for DCI 2_9-based SSB burst periodicity
adaptation for an SCell,
·
The DCI is scrambled a new
RNTI,
o
Same search space and DCI
size as that of cell DTX/DRX DCI if gNB configures both
Agreement
For
DCI 2_9-based SSB burst periodicity adaptation for an SCell,
·
the starting location of
the information block for SSB burst periodicity indication for a SCell within
the DCI format 2_9 is configured using a new RRC parameter,
·
the length of the
information block is given by ceil(log2(1+X)), where UE is configured with X
additional SSB burst periodicities for the SCell.
Agreement
For adaptation of SSB in time-domain, UE
can be configured with X (<=Xmax) additional SSB burst periodicities for an
SCell.
·
Xmax=2
Agreement
Separate configuration of the following
parameters for the additional PRACH resources at least for 4-step RACH is
supported
·
CB-PreamblesPerSSB
R1-2503085 Draft LS on DCI-based PRACH adaptation Moderator
(Ericsson)
Agreement
LS on DCI-based PRACH adaptation is endorsed with the ACTION
part modified compared to draft LS in R1-2503085
as follows:
ACTION:
RAN1 respectfully asks RAN2 to confirm whether the use of above bit is
feasible.
Final LS is approved in R1-2503086.
R1-2503054 Summary#3 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Thursday session
Agreement
For
adaptation of PRACH in time-domain, for a connected mode UE,
- One
of the reserved bits of PDCCH order (DCI 1_0 with
C-RNTI) is used for the new DCI field that indicates the availability
of additional PRACH resources.
R1-2503124 Summary#4 of AI 9.5.3 for R19 NES Moderator
(Ericsson)
From Friday session
Working Assumption
When
a UE receives in slot 
on the active DL BWP of
a first serving cell a PDCCH providing DCI format 2_9 that indicates a change
in SSB burst periodicity of the SSB transmission on a second serving cell, the
UE assumes SSB is transmitted on the second serving cell according to the
indicated SSB burst periodicity from the beginning of the first slot containing
the first
[actually] transmitted SSB within the first [possible] SSB burst according to the
indicated SSB burst periodicity that is no earlier than the slot 
of the first serving
cell where 
is a number of slots
for the SCS of the active DL BWP of the first serving cell [in Table 11.5-1 of
TS 38.213].
- FFS: how to determine the
first [possible] SSB burst.
Agreement
For
DCI-based adaptation for additional PRACH resources, the PRACH mask to identify
the subset of the additional PRACH resources is given by:
·
Option 1-2: Semi-static signalling of a PRACH mask index and a value of K (number of association pattern periods).
o
For K: one from up to four
candidate values {2,4,8, [1 or 16]}.
|
Mask
index
|
Indication
of association periods (AP) for subset of additional PRACH resources within
every K association pattern periods (APP)
|
|
0
|
1st
half of the APs in K APPs
|
|
1
|
1st
quarter of the APs in K APPs
|
|
2
|
1st eighth of the APs in K APPs
|
|
3
|
1st sixteenth of the APs in K APPs
|
Agreement
- For
DCI-based adaptation for additional PRACH resources, the reference point
for the availability of additional PRACH resources indicated by DCI 1_0
with P-RNTI is the start of first frame of the current SI modification
period where UE receives the DCI.
- The
validity duration configured by higher layer signalling for the
availability information of additional PRACH resources indicated by DCI
1_0 with P-RNTI is
- (Option
4) Multiple of SI modification period ({[1],2,[3],4,8,[],[],..}).
R1-2503125 Final Summary of AI 9.5.3 for R19 NES Moderator
(Ericsson)
Please refer to RP-250343
for detailed scope of the WI. Additional RAN guidance on Rel-19 NES can be
found in RP-243297.
[121-R19-NES] Email
discussion on Rel-19 NES enhancement – Ajit (Ericsson)
-
To be used
for sharing updates on online/offline schedule, details on what is to be
discussed in online/offline sessions, tdoc number of the moderator summary for
online session, etc
R1-2504014 Update of RAN1 RRC
parameter list for R19 NES WI Rapporteur(Ericsson)
R1-2503233 Discussion of
on-demand SSB Scell operation FUTUREWEI
R1-2503267 On-demand SSB SCell
operation for eNES Huawei, HiSilicon
R1-2503315 Discussion on
on-demond SSB for NES ZTE Corporation, Sanechips
R1-2503365 Remaining issues
on-demand SSB Scell operation vivo
R1-2503412 On-demand SSB SCell
Operation Nokia, Nokia Shanghai Bell
R1-2503416 Discussion on
on-demand SSB for SCell operation NEC
R1-2503519 Discussion on
on-demand SSB SCell operation Spreadtrum, UNISOC
R1-2503539 On-demand SSB Scell
operation for NES TCL
R1-2503570 On-demand SSB SCell
operation Samsung
R1-2503718 OD-SSB for SCELL
operation Tejas Network Limited
R1-2503737 Discussion on
on-demand SSB SCell operation Ofinno
R1-2503797 Discussion on
on-demand SSB SCell operation CATT
R1-2503835 Discussion on
on-demand SSB SCell operation CMCC
R1-2503886 Discussion on
on-demand SSB SCell operation Xiaomi
R1-2503972 Discussion on
on-demand SSB SCell operation InterDigital, Inc.
R1-2504015 On-demand SSB SCell
operation Ericsson
R1-2504030 On-demand SSB SCell
Operation Google
R1-2504037 Discussion on
on-demand SSB SCell operation KT Corp.
R1-2504050 Discussion on
on-demand SSB operation for SCell China Telecom
R1-2504075 Discussion on
remaining details of on-demand SSB operation on SCell Sharp
R1-2504092 Discussion on
on-demand SSB SCell operation Fujitsu
R1-2504107 On-demand SSB SCell
operation Lenovo
R1-2504141 Discussion on
On-demand SSB SCell operation ETRI
R1-2504176 Discussion on
On-Demand SSB SCell operation Transsion Holdings
R1-2504192 Discussion on the
enhancement to support on demand SSB SCell operation OPPO
R1-2504235 Discussion on
on-demand SSB SCell operation Panasonic
R1-2504247 On-demand SSB SCell
operation LG Electronics
R1-2504262 On-demand SSB SCell
operation MediaTek Inc.
R1-2504325 On-demand SSB SCell
Operation Apple
R1-2504398 On-demand SSB
operation for Scell Qualcomm Incorporated
R1-2504505 Discussion on
on-demand SSB SCell operation NTT DOCOMO, INC.
R1-2504538 Discussion on
on-demand SSB SCell operation ITRI
R1-2504554 Discussion on
on-demand SSB SCell operation KDDI Corporation
R1-2504558 DCI based signaling
for on-demand SSB ASUSTeK
R1-2504602 Discussion on
on-demand SSB Scell operation CEWiT
R1-2504744 Summary
#1 of on-demand SSB for NES Moderator (LG Electronics)
Agreement
For a cell supporting on-demand SSB SCell operation,
- The following cases are NOT supported in Rel-19.
- AO-SSB
is CD-SSB and not on a synchronization raster.
- OD-SSB is CD-SSB and on sync-raster.
- When AO-SSB is not CD-SSB, the center frequency of AO-SSB is
different from the center frequency of OD-SSB.
- When the center frequency locations of always-on SSB and on-demand SSB are different, OD-SSB is not CD-SSB.
Agreement
For a cell supporting on-demand SSB SCell operation, the following
is supported for QCL between different OD-SSB configurations
- SS/PBCH blocks with
the same SSB indexes according to OD-SSB configuration and indication are quasi co-located with respect to
Doppler spread, Doppler shift, average gain, average delay, delay spread,
and when applicable, spatial RX parameters.
- When a signal/channel is configured to be QCLed with a SSB
index, the signal/channel is QCLed with the same SSB index according to
OD-SSB configuration and indication with the same
QCL parameters according to existing specifications.
- FFS: Case where there is different SSB
indexes before and after OD-SSB transmission adaptation
Conclusion
For a cell supporting on-demand SSB SCell
operation,
·
LTM based on OD-SSB is NOT
supported in Rel-19.
·
L1 measurement based on
OD-SSB for a serving cell in Scenario #2 is NOT supported in Rel-19.
o
Note: As per previous RAN1
agreement, Scenario #2 is when SCell is configured to a UE but before the UE receives SCell
activation command (e.g., as defined in TS 38.321).
·
L1 measurement based on
OD-SSB for a non-serving/neighbor cell is NOT supported in Rel-19.
R1-2504745 Summary
#2 of on-demand SSB for NES Moderator (LG Electronics)
Agreement
For a cell supporting on-demand SSB SCell
operation,
·
If
a PDCCH candidate and a currently
being transmitted OD-SSB are
overlapped in at least one RE, the UE is not required to monitor the PDCCH
candidate.
Agreement
For a UE supporting on-demand SSB SCell
operation,
·
When receiving PDSCH scheduled by PDCCH with CRC scrambled by
C-RNTI, MCS-C-RNTI, CS-RNTI, G-RNTI, G-CS-RNTI, MCCH-RNTI, Multicast MCCH-RNTI
or PDSCHs with SPS.
o At least the UE shall assume that the PRBs containing currently being transmitted
OD-SSB resources are not available for PDSCH in the OFDM symbols where OD-SSB
is currently being transmitted on the cell.
Agreement
For a cell supporting on-demand SSB SCell
operation and for Case #1 (i.e., No always-on
SSB on the cell),
·
For
RO validation before SSB-to-RO mapping,
o Alt 3: RO validation rule is
determined based on all configured OD-SSB configuration(s) in RRC.
·
For
SSB-to-RO mapping,
o SSB-to-RO mapping rule is determined based on all
the SSB indices configured by all configured value(s) of od-ssb-PositionsInBurst
in RRC.
Conclusion
For a cell supporting on-demand SSB SCell operation,
- Whether or not to assume quasi co-location between different
SSB indices is up to UE implementation
R1-2504746 Summary
#3 of on-demand SSB for NES Moderator (LG Electronics)
Agreement
For a cell supporting on-demand SSB SCell
operation,
·
For
OD-SSB, the SS/PBCH block in TS 38.213 Clause 11.1 can be replaced by the
SS/PBCH block that is transmitted according to an on-demand SSB transmission
operation in the cell.
Note: Whether/How to capture the above is up to the editor.
Agreement
For a cell supporting on-demand SSB SCell
operation, it is supported to use OD-SSB as
·
PL-RS,
·
Reference
signal for QCL/TCI configuration, or
·
Candidate
beam detection for beam failure recovery.
Note: Whether/How to capture the above is up to the editor.
Agreement
For a cell supporting on-demand SSB SCell operation, the following
combinations are supported.
·
For OD-SSB transmission activation (OD-Tact)
and OD-SSB transmission adaptation (OD-TA),
o
Case A1: RRC-based OD-Tact without N (i.e., od-ssb-nrofBurst)
configured + MAC CE-based OD-TA;
§
Subject to UE capability
o
Case B1: MAC CE-based OD-Tact without N configured + MAC CE-based OD-TA;
o
Case B2: MAC CE-based OD-Tact with N configured + MAC CE-based OD-TA.
·
For
OD-SSB transmission deactivation
(OD-TD),
o Case X1: RRC-based OD-Tact
without N configured +
MAC CE-based OD-TD;
§
Subject to UE capability
o Case Y1: MAC CE-based OD-Tact
or OD-TA without N configured + MAC CE-based
OD-TD;
o Case Y2: MAC CE-based OD-Tact
or OD-TA with N configured + implicit
OD-TD;
o Case Y3: MAC CE-based OD-Tact
or OD-TA with N configured + MAC CE-based
OD-TD.
·
Conclusion: There is no RAN1 consensus to
support RRC activation of OD-SSB transmission configuring od-ssb-nrofBurst.
·
Note:
“Implicit OD-TD” above implies that the on-demand SSB is deactivated based on
the value for od-ssb-nrofBurst according to NW indication.
Agreement
For a cell supporting on-demand SSB SCell operation, for configuring
od-ssb-nrofBurst of which the
value range is {N2 integer values},
·
N2= 8
o Note: This is updated from the previous RAN1 agreement.
·
The following values for od-ssb-nrofBurst
are taken as the starting point and to be confirmed in RAN1#122
o
For FR1, the value range of
od-ssb-nrofBurst is {5, 10, 15, 20, 25, 30, 40, 50}.
o
For FR2, the value range of
od-ssb-nrofBurst is {25, 30, 40, 50, 75, 100, 150, 200}.
Agreement
For a cell supporting on-demand SSB SCell
operation and for Case #2 (i.e., Always-on SSB is periodically
transmitted on the cell),
·
For
RO validation before SSB-to-RO mapping,
o Alt 3: RO validation rule is
determined based on all configured AO-SSB and OD-SSB configuration(s) in RRC.
·
For
SSB-to-RO mapping,
o SSB-to-RO mapping rule is determined based on all
the SSB indices configured by all configured value(s) of od-ssb-PositionsInBurst
and SSB indices configured for AO-SSB in RRC.
·
NW
to ensure that the SSB to RO mapping is the same between different UEs under
the same serving cell.
Agreement
·
For a cell supporting on-demand SSB SCell
operation,
o
For Case #1 (i.e., No
always-on SSB on the cell),
§
A CSI report configuration
is associated with OD-SSB only,
·
UE reports SSBRI based on SSB-index
corresponding to the currently being transmitted OD-SSB.
o
For Case #2 (i.e., Always-on SSB is periodically
transmitted on the cell),
§
For the case where AO-SSB
and OD-SSB have the same center frequency,
·
A CSI report configuration
is associated with both of AO-SSB and OD-SSB,
·
UE reports SSBRI based on SSB-index
corresponding to AO-SSB and/or based on SSB-index corresponding to the
currently being transmitted OD-SSB. Which SSB(s) is(are) used is up to UE
implementation as long as RAN4 requirements are met.
§
For the case where AO-SSB
and OD-SSB have the different center frequencies,
·
Option 2: A CSI report
configuration is associated with both of AO-SSB and OD-SSB.
o
UE reports SSBRI based on SSB-index
corresponding to AO-SSB and/or based on SSB-index corresponding to the
currently being transmitted OD-SSB. Which SSB(s) is(are) used is up to UE
implementation as long as RAN4 requirements are met.
o
SSBRI k (k ≥ 0)
corresponds to the configured (k+1)-th entry of the associated csi-SSB-ResourceList
in the corresponding CSI-SSB-ResourceSet.
·
Note: The CSI report in the above agreement
applies only to what is supported up to Rel-18.
Agreement
For a cell supporting on-demand SSB SCell
operation and for L1
measurement based on on-demand SSB,
·
For
a CSI report configuration configured with reportConfigType set to periodic,
o Do not support periodic CSI reporting based
on OD-SSB, for Case #1 and Case #2
R1-2503234 Discussion of
on-demand SIB1 for idle/inactive mode UEs FUTUREWEI
R1-2503268 Discussion on
on-demand SIB1 for eNES Huawei, HiSilicon
R1-2503316 Discussion on
on-demand SIB1 for NES ZTE Corporation, Sanechips
R1-2503366 Remaining issues
on-demand SIB1 for idle/inactive mode UEs vivo
R1-2503413 On-demand SIB1 for
Idle/Inactive mode UEs Nokia, Nokia Shanghai Bell
R1-2503417 Discussion on
on-demand SIB1 for UEs in idle/inactive mode NEC
R1-2503520 Discussion on
on-demand SIB1 for idle/inactive mode UEs Spreadtrum, UNISOC
R1-2503571 On-demand SIB1 for
idle/inactive mode UEs Samsung
R1-2503717 OD-SIB1 for
idle/inactive UEs Tejas Network Limited
R1-2503738 Discussion on
on-demand SIB1 for idle/inactive mode UEs Ofinno
R1-2503798 Discussion on
on-demand SIB1 CATT
R1-2503836 Discussion on
on-demand SIB1 for UEs in idle/inactive mode CMCC
R1-2503887 Discussion on
on-demand SIB1 for idle/inactive mode UEs Xiaomi
R1-2503973 Discussion on
on-demand SIB1 for idle/inactive mode UEs InterDigital, Inc.
R1-2503999 Discussion on
on-demand SIB1 transmission for network energy savings Fujitsu
R1-2504016 On-demand SIB1 for
UEs in idle/inactive mode for NES Ericsson
R1-2504031 On-demand SIB1 for
Idle/Inactive Mode UE Google
R1-2504051 Discussion on
on-demand SIB1 for idle/inactive mode UEs China Telecom
R1-2504065 On-demand SIB1 for
idle/inactive mode UEs Sony
R1-2504108 On-demand SIB1 for
idle/inactive mode UEs Lenovo
R1-2504142 On-demand SIB1 for
idle/inactive mode UEs ETRI
R1-2504177 Discussion on
on-demand SIB1 transmission for idle/inactive mode UEs Transsion
Holdings
R1-2504193 Discussion on the
enhancement to support on demand SIB1 for idle/inactive mode UE OPPO
R1-2504236 Discussion on
on-demand SIB1 for idle/inactive mode UEs Panasonic
R1-2504248 On-demand SIB1 for
idle/inactive mode UEs LG Electronics
R1-2504263 On-demand SIB1 for
idle or inactive mode UEs MediaTek Inc.
R1-2504326 On On-demand SIB1 for
IDLE/INACTIVE mode UEs Apple
R1-2504399 On-demand SIB1
procedure Qualcomm Incorporated
R1-2504457 Discussion on
on-demand SIB1 for idle/inactive mode UEs DENSO CORPORATION
R1-2504467 Discussion on
on-demand SIB1 transmission for idle UEs Sharp
R1-2504506 Discussion on
on-demand SIB1 for idle/inactive mode UEs NTT DOCOMO, INC.
R1-2504556 Discussion on
on-demand SIB1 in idle/inactive mode CAICT
R1-2504603 Discussion on
on-demand SIB1 CEWiT
R1-2504679 FL
summary 1 for on-demand SIB1 in idle/inactive mode Moderator (MediaTek)
Conclusion
On whether/how to indicate additional
information related to SSBs associated with PDCCH monitoring occasions, no
additional information is provided
Conclusion
For the purpose of finalizing Rel-19 NES,
RAN1 assumes the following UE behavior for OD-SIB1.
-
The SIB1 is transmitted on
the DL-SCH with a periodicity of 160 ms and variable transmission repetition
periodicity within 160 ms.
Agreement
On the value range for od-sib1-duration,
adopt the following:
-
{20, 40, 80, 160, 320} ms
Agreement
For UE to obtain the UL point A for TDD
system, configure offsetToPointA in the UL WUS configuration for TDD
system.
·
No RAN1 specification
impact is expected
Conclusion
There is no consensus on the support of OD-SIB1 for NR-U in Rel-19.
R1-2504680 FL summary 2 for on-demand SIB1 in idle/inactive mode Moderator (MediaTek)
Agreement
RAN1 to adopt TP below.
--------------- TP of TS 38.213 in Clause 23 -----------------------
If the UE identifies a RAPID associated
with a corresponding PRACH transmission from the UE in a PDSCH reception
scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI, the UE can
be indicated by higher layers to monitor PDCCH on the
second cell to detect a DCI format 1_0 with CRC
scrambled by the SI-RNTI according to a Type0-PDCCH CSS set provided by
SearchSpaceZero. If the UE is provided XYZ, the UE monitors PDCCH
only in monitoring occasions associated with the SS/PBCH block. The UE starts monitoring monitors
PDCCH to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI after a number of slots provided by od-sib1-windowStartOffset from the
starting slot of the window controlled by ra_ResponseWindow, and for a
number of slots provided by od-sib1-WindowDuration.
--------------- end of TP
-------------------------------------------------------
Reason of change: Considering the RAR processing time and
OD-SIB1 window starting time may fall into the middle of SSB burst and/or SIB1
transmission time corresponding to one SSB burst, when to start the PDCCH
monitoring in the OD-SIB1 window is up to UE implementation.
Agreement
The parameters ‘absoluteFrequencyPointA’,
‘offsetToCarrier’ and ‘locationAndBandwidth’ are
mandatorily present in the UL-WUS configuration for both FDD and TDD system.
Agreement
The frequencyBandList
is mandatorily present in WUS configuration for TDD system, which refers to the
IE within FrequencyInfoDL-SIB.
Agreement
The reference point to determine the
starting slot of on-demand SIB1 window is the start of the slot containing the
starting symbol of the RAR window.
Agreement
RAN1 adopts TP below for clause 23 of TS 38.213.
|
23 UE
procedure to request SIB1 reception
-----------------------omitted
text-----------------------
[If the SS/PBCH
block on the second cell indicates  for FR1 or  for FR2,] the UE is not required to monitor
PDCCH on the second cell to detect the DCI format 1_0 with CRC scrambled by the SI-RNTI prior to a
reception of a PDSCH carrying a RAPID associated
with a corresponding PRACH transmission scheduled by the DCI format 1_0 with CRC scrambled by the RA-RNTI.
|
R1-2503235 Discussion of the
adaptation of common signal/channel transmissions FUTUREWEI
R1-2503269 On common
channel/signal adaptation for eNES Huawei, HiSilicon
R1-2503317 Discussion on common
signal channel for NES ZTE Corporation, Sanechips
R1-2503367 Remaining issues on
adaptation of common signal/channel transmissions vivo
R1-2503414 Adaptation of common
signal/channel transmissions Nokia, Nokia Shanghai Bell
R1-2503418 Discussion on
adaptation of common signal/channel transmissions NEC
R1-2503521 Discussion on
adaptation of common signal/channel transmissions Spreadtrum, UNISOC
R1-2503572 Adaptation of common
signal/channel transmissions Samsung
R1-2503716 Adaptation of common
signals or channels Tejas Network Limited
R1-2503799 Discussion on
adaptation of common signal/channel transmissions CATT
R1-2503837 Discussion on
adaptation of common signal/channel transmissions CMCC
R1-2503867 Discussion on
adaptation of common signal/channel transmission Panasonic
R1-2503888 Discussion on
adaptation of common signal and channel transmissions Xiaomi
R1-2503974 Discussion on
adaptation of common signal/channel transmissions InterDigital, Inc.
R1-2504000 Discussion on
adaptation of common signal / channel transmissions Fujitsu
R1-2504017 Adaptation of common
signal/channel transmissions for NES Ericsson
R1-2504032 Adaptation of Common
Signals Google
R1-2504038 Discussion on
adaptation of common signal/channel transmissions KT Corp.
R1-2504052 Discussion on common
signal/channel adaptation China Telecom
R1-2504101 Discussion on
adaptation of common signal channel transmissions HONOR
R1-2504143 Adaptation of common
signal/channel transmissions ETRI
R1-2504178 Discussion on
adaptive transmission of common signal or common channel Transsion
Holdings
R1-2504194 Discussion on
adaptation of common signal/channel transmission OPPO
R1-2504249 Adaptation of common
signal/channel transmissions LG Electronics
R1-2504264 Adaptation of common
signal/channel transmissions MediaTek Inc.
R1-2504327 On adaptation of
common signal/channel for NES enhancements Apple
R1-2504400 Adaptation of common
channel transmissions Qualcomm Incorporated
R1-2504468 Discussion on
adaptation of common signal/channel transmissions Sharp
R1-2504507 Discussion on
adaptation of common signal/channel transmissions NTT DOCOMO, INC.
R1-2504547 Adaptation of common
signals and channels Lenovo
R1-2504604 Discussion on
adaptation of common signal and channel transmissions CEWiT
R1-2504757 Summary#1
of AI 9.5.3 for R19 NES Moderator (Ericsson)
Agreement
For
DCI 2_9-based SSB burst periodicity adaptation for an SCell for the case when
cell DTX/DRX is not configured, reuse existing search space configuration
parameter for DCI 2_9-based monitoring and existing DCI 2_9 size configuration
parameter and update in specification that these are also applicable to SSB
burst periodicity adaptation (when configured)
Agreement
Value d (in the WA from RAN1#120bis) is the number of slots for the SCS of
the active DL BWP of the first serving cell in Table 11.5-1 of TS 38.213.
Agreement
Update the agreement from RAN1#120bis as shown below (i.e.
updates in red).
Agreement (from RAN1#120bis)
For adaptation of PRACH in time-domain, at least for 4-step RACH, at least for DCI 1_0 with P-RNTI,
- Support
configuration of the additional PRACH resources within
[the same]
RACH-ConfigCommon in SIB1 used to configure the legacy PRACH resources
- the
legacy PRACH resources used for ‘additional RO validation before the
SSB-RO mapping’ are configured in the RACH-ConfigCommon
Note: Whether the additional PRACH configuration can be from RRC
other than SIB1 is up to RAN2.
Agreement
The
fourth candidate value for K (for PRACH subset mask) is 16. K=1 is default
value (if parameter is not configured).
Agreement
Supported
values for validity duration configured by higher layers are
-
{2,4,8,16}
x SI modification period.
Agreement
Value range for PRACH-Config Index
parameter for additional RACH configuration is same as legacy, i.e. INTEGER (0...255).
-
Note: Final decision on the
value range is up to RAN2
Conclusion
Using
DCI 1_0 with P-RNTI to explicitly deactivate the additional PRACH resources is
NOT supported.
Conclusion
There
is no consensus to support adaptation of RACH in time domain for 2-step RA in Rel-19.
R1-2504758 Summary#2
of AI 9.5.3 for R19 NES Moderator (Ericsson)
Agreement
‘PRACH resource indicator’ field is
present in DCI 1_0 with C-RNTI for PDCCH order when the configuration of the
additional RACH resources is provided in SIB1(i.e. addl-RACH-Config-Adaptation).
-
Above
applies for PCell
Agreement
When
the SSB burst periodicity is switched from periodicity value P1 to periodicity
value P2 based on DCI format 2_9 indication,
·
Alt
1: SFN offset (relative to SFN0) and half-frame index are configured per additional SSB
periodicity value.
o
the
first SSB burst according to the periodicity value P2 is determined as the
first SSB burst according to the SSB burst periodicity value P2 and associated
SFN offset and half-frame index that is no earlier than slot m+d.
SSB occasions with larger periodicity are
subset of the SSB occasions with shorter periodicity.
R1-2504890 Summary#3
of AI 9.5.3 for R19 NES Moderator (Ericsson)
Agreement
Both CBRA and CFRA based on additional PRACH resources
is supported for PDCCH order via DCI 1_0 with C-RNTI.
·
For
CFRA,
o The indicated SSB index
and PRACH mask index are applied to both legacy PRACH resources and additional
PRACH resources.
§
Note:
The PRACH mask applies to either additional resources and/or legacy resources, depending
on which one satisfies the conditions for the mask to be applicable.
Agreement
Adopt the below TP for Clause 8.1
of TS 38.213, as per Editor CR available in R1-2503167.
*** Unchanged text
omitted ***
For valid PRACH occasions associated with addl-RACH-Config-Adaptation [in RACH-ConfigCommon],
the UE can be additionally provided a PRACH mask index, by prach-SubsetMask-Index-Adaptation that, if
provided, indicates one or more association
periods per K_mask association pattern periods according to
Table 8.1-0, where K_mask is provided by KforAPPForPRACHsubsetMask.
Table 8.1-0:
Mapping of mask index to association periods per Kmask association
pattern periods
|
Mask Index
|
Association periods
(APs) perKmask association pattern periods (APPs)
|
|
0
|
First half of APs
in Kmask APPs
|
|
1
|
First quarter of APs
in Kmask APPs
|
|
2
|
First eighth of APs
in Kmask APPs
|
|
3
|
First sixteenth of
APs in Kmask APPs
|
Valid PRACH occasions
associated with addl-RACH-Config-Adaptation, and
additionally associated with in association periods indicated by prach-SubsetMask-Index-Adaptation, if
provided, are activated indicated as
available for PRACH transmission based on an indication in a DCI format
1_0 with CRC scrambled by a P-RNTI [or a C-RNTI] [5, TS 38.212]. For activation indication by DCI
format 1_0 with CRC scrambled by the P-RNTI, the PRACH occasions are available
for a duration provided by validity-DurationForAddlRACHAdaptation,
starting from the first frame of the SI modification period [12, TS 38.331]
that includes a PDCCH monitoring occasion where the UE receives a PDCCH
providing the DCI format 1_0 with CRC scrambled by the P-RNTI.
*** Unchanged text
omitted ***
Agreement
Additional
PRACH availability indication can be carried by a DCI 1_0 with P-RNTI with
Short Messages Indicator set to 00, 01,10,11.
·
Note:
Above is already reflected in the endorsed editor CR 38.212